Resolving transitive maven dependencies

[fisk]

Hi,

Love your tool. I am now moving my OSGi + maven goo used to build the coolest text editor ever (fisked) to use Java 9 modules and a tool that better supports having many modules, much like your tool.

Anyway... I use the resolve plugin to resolve maven libraries. But it does not seem to resolve their transitive dependencies as well. Or did I miss something? Just wondering if this is something anyone is looking into.

Thanks, /Erik

[forax]

yes, it's by design, at least it seems the right thing to do when i code the resolver, the main reason is that i need the user to provide a module compatible name for all dependencies that are not java 9 modules yet.

Explicitly listing the dependencies:

• so you know when the transitive dependencies change and choose how to act accordingly (split packages can be created, new dependency can be added for no good reason, etc), and
• you can select precisely the version you want, using an old version of a dependencies if there is a blocking bug until this is fixed.

Rémi

[fisk]

The pros you mentioned in the bullet list applied to the pre-jigsaw era as well though. Yet people (me included) want automatic transitive dependency resolution. Sometimes you just know that you need library X of version Y, no matter what transitive dependencies it has even if dependencies are suboptimal, or your program just won't work. Then it is nice if the dependencies are automatically resolved, downloaded and packaged, because that is exactly what you would have had to do anyway manually regardless of what those dependencies were.

Having said that, I understand the naming problem, and don't have any obvious solution for it either at this time.

[forax]

yes, you're right, everybody wants automatic dependency resolution without the hidden costs, but we do not live in the unicorn world yet, that's why pro ask its users about these trade offs.

One thing i've planned but not yet implemented is a way to be able to repackage a module like Maven shade plugin to sandbox correctly the dependencies, in that mode, i see no problem to automatically resolve the transitive dependencies.

[fisk]

That sounds like a sound idea. Looking forward to seeing that. Meanwhile, I shall manually declare my transitive dependencies.

[fcamblor]

Another option would be to "generate" a flattened resolved dependencies list in a "one shot" run

This could be useful at bootstrapping time (and everytime we want to add a new dependency-pulling-lots-of-transitive-deps).

I like the idea to not resolve transitive deps because :

• It makes things simpler (no version resolution & conflicts management)
• It makes things declarative : today, a lot of projects give the impression the have very few dependencies but those root dependencies grab a lot of transitive deps (at different levels). Having all dependencies being declared will give a true idea of the real "weight" a module would represent.

[forax]

yes, Bootstrapping is not too bad currently, you add the requires in the module-info, you add association between the module name and the Maven artifact id in the resolver.dependencies, run pro and follow the error messages. Doing it in the other way, i.e. provide the Maven artifact id first means that there is a good way to extract the module name from a Maven jars, this is possible if there is a module-info or the name in the MANIFEST, but a lot of maven jars are still not module aware with no good way to find a name apart asking the user.

[forax]

I've just added a subcommand named "resolve" that allow to list the dependencies of a maven artifact using the same format as module.dependencies().

By example,

$ pro resolve org.junit.jupiter:junit-jupiter-api:[0,]
org.apiguardian.api=org.apiguardian:apiguardian-api:1.0.0
org.junit.jupiter.api=org.junit.jupiter:junit-jupiter-api:5.2.0-RC1
org.junit.platform.commons=org.junit.platform:junit-platform-commons:1.2.0-RC1
org.opentest4j=org.opentest4j:opentest4j:1.0.0

[forax]

I close this isssue as resolving transitive dependencies by shading requires merging the module-infos of the module and its dependencies creating a different configurations.

So i don't think this issue can be fixed.