Yes, seems to be a Problem in 1.2.x, downgrade to 1.1.x seems to be the Workaround: https://github.com/moditect/moditect/issues/254
Am Di., 24. Juni 2025 um 13:02 Uhr schrieb Gary Gregory < garydgreg...@gmail.com>: > 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 <my-spam-...@gmx.net.invalid> 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 <software_fr...@runbox.com.invalid> > > 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 <garydgreg...@gmail.com> > > wrote: > > >>> > > >>> On Sun, Jun 22, 2025 at 5:01 PM Frank <software_fr...@runbox.com > > .invalid > > >> <mailto:software_fr...@runbox.com.invalid>> 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 <garydgreg...@gmail.com> > > >> 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 < > garydgreg...@gmail.com > > > > > >> 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 <software_fr...@runbox.com > > .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: user-unsubscr...@commons.apache.org > > >>>>>>> For additional commands, e-mail: user-h...@commons.apache.org > > >>>>>>> > > >>>>> > --------------------------------------------------------------------- > > >>>>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > > >>>>> For additional commands, e-mail: user-h...@commons.apache.org > > >>>>> > > >>>> > > >>>> > --------------------------------------------------------------------- > > >>>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > > >>>> For additional commands, e-mail: user-h...@commons.apache.org > > >>>> > > >>> --------------------------------------------------------------------- > > >>> To unsubscribe, e-mail: user-unsubscr...@commons.apache.org <mailto: > > >> user-unsubscr...@commons.apache.org> > > >>> For additional commands, e-mail: user-h...@commons.apache.org > <mailto: > > >> user-h...@commons.apache.org> > > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: user-unsubscr...@commons.apache.org > > For additional commands, e-mail: user-h...@commons.apache.org > > > > >
