Let me elaborate a bit - recent use case was when 2 jars were exporting same
package (such was fine in old classpath use case, but not anymore for Java
modules case). And challenge was to figure out which exactly jar needs to be
excluded from Java modules resolution graph to make overall Java Modules
validation work and not lead to a conflict.
Presence of either of those jars would satisfy obviously compilation, so issue
here is not about compilation itself. With proposed exclude approach it would
be much easier to exclude jar1 - do various evaluations/tests and if anything
failing - switch to jar2. And do all that yet not touching Maven (other build
tool) dependencies aggregation inside some folder/local repo. And once reaching
point of passing set - adjust later dependencies in other places.
And in that regards mentioned --limit-modules would be longer path to achieve
above fast evaluation of impact.
On Monday, August 1, 2022 at 09:53:53 AM GMT+1, Alan Bateman
<[email protected]> wrote:
On 21/07/2022 14:24, Andrejus Chaliapinas wrote:
Hi,
While dealing with long list of Jar dependencies for complex Maven project
and trying to resolve some of Java Modules conflicts - I'm finding that
sometimes it could be useful to exclude some modules without yet removing
actual jar file from aggregated directory of dependencies.
In that regards something like --exclude-modules would help initially to
evaluate impact and later allow adjust build/dependencies resolution logic.
What do you think?
I don't think this make sense as code will not compile or run if you
dependences are removed. Have you found modules where the author has included
`requires` clauses for modules that aren't actually required, or maybe you are
dealing with a module path with many automatic modules and your module is being
compiled with --add-modules ALL-MODULE-PATH?
One option to be aware of is the --limit-modules option [1] but I suspect it
won't be useful to you right now.
-Alan
[1] https://openjdk.org/jeps/261#Limiting-the-observable-modules
