Hello Kolja, Thank you for the clarification. Would you say this is a bug in the Moditect Maven plugin? Because it doesn't follow the JAR specification?
Ty, Gary On Tue, Jun 24, 2025, 06:47 Kolja <[email protected]> wrote: > Hi, > > see also > > https://github.com/eclipse-jdt/eclipse.jdt.core/issues/2495#issuecomment-2254297050 > > The problem is that the commons-cli jar misses directory entries for > 'versions/9/' under 'META-INF'. > The module-info.class was somehow added without them. > > The eclipse module name resolver used for the classpath looks for > directories, does not find them and then reverts to deriving the > modulename from the filename. > [ > https://github.com/eclipse-jdt/eclipse.jdt.core/blob/ed787f542d5509ba226f0b8b06982d61e81b4622/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/core/builder/ClasspathMultiReleaseJar.java#L83-L85 > ] > > Hopefully someone can fix that for commons-cli and maybe check other > commons artifacts. > > br, > Kolja > > On 23.06.2025 01:09, Gary Gregory wrote: > > Hopefully you can create an m2e ticket and post a link to it here. > > > > Ty, > > Gary > > > > > > > > On Sun, Jun 22, 2025, 18:50 Frank <[email protected]> > wrote: > > > >> BTW, Just opened the project in IntelliJ. Maven POM is unchanged except > >> to up the Commons CLI version to 1.9.0. No problems with module > detection. > >> F. > >> > >>> On Jun 22, 2025, at 14:25, Gary Gregory <[email protected]> > wrote: > >>> > >>> On Sun, Jun 22, 2025 at 5:01 PM Frank <[email protected] > .invalid > >> <mailto:[email protected]>> wrote: > >>>> I added your snapshot repo, changed my pom.xml and verified in Eclipse > >> that I was truly using commons-cli-1.10.0-SNAPSHOT.jar. Unfortunately, > I > >> still see the same problem. org.apache.commons.cli is not recognized > as a > >> module. I have no trouble believing that M2E is the culprit. I've had > to > >> put other workarounds in place to avoid its limitations. If Eclipse > >> doesn't support some feature of Maven, M2E won't have it. > >>>> In the jar, I can see a module-info.class, but the source does not > >> provide it from a simple module-info.java and I don't know how the > class is > >> built. Would you have changed the module name at any point? > >>> We use the Moditect Maven plugin to build the JPMS metadata through > >>> the commons-parent POM and properties defined in that POM and in the > >>> POM for CLI. > >>> > >>> Gary > >>> > >>>> Thanks again, > >>>> Frank > >>>> > >>>>> On Jun 22, 2025, at 13:30, Gary Gregory <[email protected]> > >> wrote: > >>>>> Hm I think our OSGi tests don't run since we ported to JUnit 5. > >>>>> > >>>>> Gary > >>>>> > >>>>> On Sun, Jun 22, 2025 at 3:26 PM Gary Gregory <[email protected] > > > >> wrote: > >>>>>> Hello Frank, > >>>>>> > >>>>>> Are you saying that no matter what version of Commons CLI you use > and > >>>>>> then build from the command line with Maven, all is well? > >>>>>> > >>>>>> If the above is true, then this suggests one of two things: > Something > >>>>>> is wrong with M2E or something is wrong with the OSGi metadata in > >>>>>> Commons CLI, > >>>>>> > >>>>>> I don't know if OSGi matters to M2E but you'd hope it wouldn't since > >>>>>> most JARs out there don't have OSGi metadata. > >>>>>> > >>>>>> CLI 1.10.0-SNAPSHOT fixes this OSGi issue (see changes.xml): > >>>>>> > >>>>>>> Remove -nouses directive from maven-bundle-plugin. OSGi package > >> imports now state 'uses' definitions for package imports, this doesn't > >> affect JPMS (from org.apache.commons:commons-parent:80) > >>>>>> I would test with a local build of git master or 1.10.0-SNAPSHOT > from > >>>>>> our snapshot Maven repository: > >>>>>> https://repository.apache.org/content/repositories/snapshots/ > >>>>>> > >>>>>> This would tell us if the OSGi fix above matters. > >>>>>> > >>>>>> You could also write a test and submit a PR that tests loading > Commons > >>>>>> CLI using OSGi in the same way as Commons Compress in the test > package > >>>>>> org.apache.commons.compress.osgi > >>>>>> > >>>>>> HTH, > >>>>>> Gary > >>>>>> > >>>>>> On Sun, Jun 22, 2025 at 1:39 PM Frank <[email protected] > .invalid> > >> wrote: > >>>>>>> Hello, > >>>>>>> > >>>>>>> I have a Java project with a Maven build in which a module uses > >> commons-cli. With version 1.9.0, the Maven build works correctly from > the > >> command line, but Eclipse and VS Code give an error that > >> org.apache.commons.cli cannot be resolved to a module. The strange > thing > >> is that if I drop back to version 1.6.0, the error disappears. The > command > >> line build and the IDE build both work. Any version after that produces > >> the issue. Eclipse lists the commons-cli jar in the Maven dependencies > for > >> any version used and they are physically present in ~/.m2. Adding it > >> manually to the module path does not help. > >>>>>>> This is doubtless some problem buried in M2e, but I have not been > >> able to resolve it for some time. I'm wondering if you can provide any > >> insight into what changed after 1.6.0 regarding the configuration as a > Java > >> 9+ module. The error occurs when the system encounters 'requires > >> transitive org.apache.commons.cli;' in module-info.java. > >>>>>>> The project is fully modularized and built with Java 21 and Maven > >> 3.9+. > >>>>>>> Thanks in advance, > >>>>>>> Frank > >>>>>>> > --------------------------------------------------------------------- > >>>>>>> To unsubscribe, e-mail: [email protected] > >>>>>>> For additional commands, e-mail: [email protected] > >>>>>>> > >>>>> --------------------------------------------------------------------- > >>>>> To unsubscribe, e-mail: [email protected] > >>>>> For additional commands, e-mail: [email protected] > >>>>> > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] <mailto: > >> [email protected]> > >>> For additional commands, e-mail: [email protected] <mailto: > >> [email protected]> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
