Ergonomic, hermetic, user-friendly software build system for Python, Go, Java, Kotlin, Protobuf, Scala, Shell. Pants lets you fearlessly scale up your codebase!

Pants

I have refs that do not have artifacts, and therefore do not get modules--but they do represent nodes in the caller graph and need to be there so transitive dependencies are properly linked up

So far I've just been doing this by adding them to the `_deps_by_caller` ref graph, but not adding them to `modules_by_ref` or `_artifacts_by_ref`

Because `module` could have _multiple_ artifacts, which also meant that it could legitimately have _empty_ artifacts

<@U053HNE90>: rather than either of those, it should probably be looking at the compile_classpath product

which is a parsed representation of the ivy info

So missing dep detection is the last holdout using the old product?

If `ivy_jar_products` wasn't needed downstream I wouldn't have to populate it at all from our resolver -- which already populates `compile_classpath` properly anyway

```  def _populate_compile_classpath(self):
    products = self.context.products
    compile_classpath = products.get_data('compile_classpath', UnionProducts)
    for target in self.context.targets(predicate=lambda t: t in self.all_jar_libs):
      artifact_paths = []
      for coord in self.target_to_maven_coordinate_closure[target.id]:
        for artifact in self.maven_coordinate_to_provided_artifacts[coord]:
          artifact_paths.append(os.path.join(self.artifact_symlink_dir, artifact.artifact_path))
      compile_classpath.add_for_target(target, [('default', entry) for entry in artifact_paths])```

_far_ cleaner than the hoops I have to jump through to populate `ivy_jar_products`

<@U053HNE90>: I don’t want to state the obvious, but there was a recent change to `ivy_jar_products`. It used to contain IvyArtifact instances, now it contains strings

This broke one of our internal plugins during our last upgrade

I'm neck deep in hadoop right now so I can't tackle this general refactor, though I strongly agree with you that this should be using the `compile_classpath` product

For now I'm going to patch around the issue internally and move on

...whoa. i just realized why declaring/inferring direct deps could be valuable.

you only need to provide direct deps to the compiler

Pants UI/behavior question. Let's say I have this command: `./pants test examples/tests/java/org/pantsbuild/example/hello/greet --no-test-junit-suppress-output --test-junit-test=org.pantsbuild.example.hello.greet.GreetingTest_THIS_CLASS_DOESNT_EXIST`

should pants print a warning that it couldn't find the invalid class &amp; carry on?