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>
