JPMS

[palexdev]

Any plan on making this compatible with modular projects?
I'm having a very hard time here trying to make it work with Gradle's extraJavaModuleInfo

[lprimak]

Do you have a specific issue? I use resolver with modular apps all the time

[palexdev]

Do you have a specific issue? I use resolver with modular apps all the time

When I add this requires shrinkwrap.resolver.api.maven to the module-info I get this error: error: module not found: shrinkwrap.resolver.api.maven

[lprimak]

Oh, I see, are you trying to use the API outside tests?
Tests aren't usually modularized (mine aren't) so I don't see this problem.
However, I still think that should be usable from JPMS:

Have you tried requires org.jboss.shrinkwrap.resolver.api.mavn?

[palexdev]

It's not a matter or names
Modules support is missing. I wonder if something like this could be done here too

[lprimak]

By default, automatic module naming takes place, based on the dependency filename.
See https://stackoverflow.com/questions/46741907/what-is-an-automatic-module

While specific module support is nice, it's unnecessary to support JPMS clients

[palexdev]

Yeah the automatic module name should work but for some reason it does not
I'm migrating to a modular library for now

[lprimak]

I think we are trying to say the same thing...
if you get the name right it should work

[palexdev]

Here's a MRE
Small Gradle project, use the run task to execute the main class

[lprimak]

Maven please... I don't use gradle :)

[palexdev]

Maven please... I don't use gradle :)

Not even IntelliJ?

[lprimak]

This is a debugging / troubleshooting / exploration task. I really don't want to learn a new build tool :)
IntelliJ doesn't do well with automatic modules, as I had problems building with IntelliJ but it would build correctly in maven command line.

Maybe that's the root cause of your problem.

[palexdev]

So, at this point, I don't really know if it's a Gradle issue or what: Documentation.

One thing is certain: it's disappointing to see such a useful library in 2024 still targeting JDK 8 and lacking proper module support. JDK 9 was released in 2017, with JDK 11 following the next year — it's time to move on, folks.

Finally, as mentioned before, I’m transitioning to another library with proper modules support. Feel free to close this issue or keep it open as a reminder for future improvement.

[lprimak]

ShrinkWrap resolver is tested up to JDK 17 now, so it fully supports JDK 17. JDK 8 is coincidental / legacy as you mentioned, and it's still supported because there is no downside right now.

The library is primarily used for testing, and testing realm isn't really modularized often, so your issue here is really an outlier.

Will keep the issue open, and it's good practice to put in the MANIFEST.MF entry for automatic module support.
However, I really don't think this is in any way related to the problem your are facing.