Re: Strange Behavior with Commons-CLI

--00000000000074185906384f41b7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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/ed787f542d5509ba226f=
0b8b06982d61e81b4622/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/co=
re/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 exce=
pt
> >> 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=E2=80=AFPM Frank <software_frank@runbox.=
com
> .invalid
> >> <mailto:[email protected]>> wrote:
> >>>> I added your snapshot repo, changed my pom.xml and verified in Eclip=
se
> >> 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 ha=
d
> 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=E2=80=AFPM Gary Gregory <garydgregory@=
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 sin=
ce
> >>>>>> 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=E2=80=AFPM Frank <software_frank@runb=
ox.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 produc=
es
> >> the issue.  Eclipse lists the commons-cli jar in the Maven dependencie=
s
> 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 an=
y
> >> 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]
>
>

--00000000000074185906384f41b7--