ancient-vegetable-10556
09/20/2021, 6:16 PMpublic void beep(ToolSetup com) {
System.out.println(com.toolchain.you.Get.the.picture);
}
You can figure out if com.toolchain.you.Get
is a real type if you know the real list of classes that are available on the classpath, but Pants’ approach is to not specify the entire dependency list, especially if we’re going to make Fat JARs.
Proposed Solution: When resolving the lockfile for a project, we walk the zip
index of each dependency JAR we pull down. At this point, we can note the packages that are included with each locked JAR, and save that to a metadata file.
At dependency scan time, we can search for strings of the form x.y…z
and look for prefixes that match a known package name, and include the JARs that provide that package on the classpath.
This will produce an overspecified classpath (if there are package prefixes that are ambiguous with variable names, we may specify more dependency classes than are actually there), but AIUI, overspecifying a classpath is not a correctness issue, but a file size issue.
Any thoughts before I commit this to a GH issue? @witty-crayon-22786 @bored-art-40741witty-crayon-22786
09/20/2021, 6:46 PMancient-vegetable-10556
09/20/2021, 6:49 PMwitty-crayon-22786
09/20/2021, 6:50 PMwe’re probably fine with an overspecified dependency spec as long as it captures everythinghmm… what do you mean by that?
bored-art-40741
09/20/2021, 10:02 PMwitty-crayon-22786
09/20/2021, 10:04 PMThere is no such escape hatch for fixing a dep that inference incorrectly inferredthere is: we support a
!
syntax in the dependency list. but the other part is true: it’s hard to detect.ancient-vegetable-10556
09/20/2021, 10:05 PMwitty-crayon-22786
09/20/2021, 10:05 PMbored-art-40741
09/20/2021, 10:05 PM!
escape hatch is infeasibleimport Foo.blah
where it looks like it's probably importing from a type already in scope based on the name)ancient-vegetable-10556
09/20/2021, 10:10 PMbored-art-40741
09/20/2021, 10:12 PMwitty-crayon-22786
09/20/2021, 10:12 PMbored-art-40741
09/20/2021, 10:12 PMancient-vegetable-10556
09/20/2021, 10:13 PMwitty-crayon-22786
09/20/2021, 10:13 PMbored-art-40741
09/20/2021, 10:15 PMancient-vegetable-10556
09/20/2021, 10:15 PMbored-art-40741
09/20/2021, 10:15 PMancient-vegetable-10556
09/20/2021, 10:17 PMbored-art-40741
09/20/2021, 10:18 PMancient-vegetable-10556
09/20/2021, 10:18 PMbored-art-40741
09/20/2021, 10:18 PMancient-vegetable-10556
09/20/2021, 10:21 PMbored-art-40741
09/20/2021, 10:22 PMancient-vegetable-10556
09/20/2021, 10:23 PMcom.foo
, I can’t implicitly refer to types in com.foo.bar
without importing them, right?bored-art-40741
09/20/2021, 10:23 PMancient-vegetable-10556
09/20/2021, 10:24 PMbored-art-40741
09/20/2021, 10:24 PMancient-vegetable-10556
09/20/2021, 10:24 PMbored-art-40741
09/20/2021, 10:24 PMancient-vegetable-10556
09/20/2021, 10:25 PMbored-art-40741
09/20/2021, 10:25 PMpackage org.pantsbuild.example;
public class B {}
class C {}
package org.pantsbuild.example;
import org.pantsbuild.example.C;
public class A {
public static void main(String[] args) throws Exception {
C c = new C();
}
}
ancient-vegetable-10556
09/20/2021, 10:26 PMbored-art-40741
09/20/2021, 10:26 PMancient-vegetable-10556
09/20/2021, 10:29 PMbored-art-40741
09/20/2021, 10:29 PMfoo.bar.Baz
but nothing had the package foo.bar
, I'd end up depending on everything that provided a package with a prefix of foo. ...
com
or org
is disasterous