Re: Strange Behavior with Commons-CLI

Yes, the lilnk is helpful.  Moditech seems to think it is only a problem =
when compiling within Eclipse, but my experience is that anything that =
uses M2E will be affected.  That's a larger pool.
F.

> On Jun 24, 2025, at 04:58, Gary Gregory <[email protected]> =
wrote:
>=20
> Thanks for the link, hopefully we can get some feedback soon.
>=20
> Gary
>=20
>=20
> On Tue, Jun 24, 2025, 07:31 Ruby Paasche <[email protected]> =
wrote:
>=20
>> 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
>>=20
>>=20
>>=20
>>=20
>> Am Di., 24. Juni 2025 um 13:02 Uhr schrieb Gary Gregory <
>> [email protected]>:
>>=20
>>> Hello Kolja,
>>>=20
>>> 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?
>>>=20
>>> Ty,
>>> Gary
>>>=20
>>> On Tue, Jun 24, 2025, 06:47 Kolja <[email protected]> =
wrote:
>>>=20
>>>> Hi,
>>>>=20
>>>> see also
>>>>=20
>>>>=20
>>>=20
>> =
https://github.com/eclipse-jdt/eclipse.jdt.core/issues/2495#issuecomment-2=
254297050
>>>>=20
>>>> 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.
>>>>=20
>>>> 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.
>>>> [
>>>>=20
>>>=20
>> =
https://github.com/eclipse-jdt/eclipse.jdt.core/blob/ed787f542d5509ba226f0=
b8b06982d61e81b4622/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/co=
re/builder/ClasspathMultiReleaseJar.java#L83-L85
>>>> ]
>>>>=20
>>>> Hopefully  someone can fix that for commons-cli and maybe check =
other
>>>> commons artifacts.
>>>>=20
>>>> br,
>>>> Kolja
>>>>=20
>>>> On 23.06.2025 01:09, Gary Gregory wrote:
>>>>> Hopefully you can create an m2e ticket and post a link to it here.
>>>>>=20
>>>>> Ty,
>>>>> Gary
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> On Sun, Jun 22, 2025, 18:50 Frank <[email protected]
>> .invalid>
>>>> wrote:
>>>>>=20
>>>>>> 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.
>>>>>>=20
>>>>>>> On Jun 22, 2025, at 14:25, Gary Gregory <[email protected]>
>>>> wrote:
>>>>>>>=20
>>>>>>> On Sun, Jun 22, 2025 at 5:01=E2=80=AFPM 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.
>>>>>>>=20
>>>>>>> Gary
>>>>>>>=20
>>>>>>>> Thanks again,
>>>>>>>> Frank
>>>>>>>>=20
>>>>>>>>> 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.
>>>>>>>>>=20
>>>>>>>>> Gary
>>>>>>>>>=20
>>>>>>>>> On Sun, Jun 22, 2025 at 3:26=E2=80=AFPM Gary Gregory <
>>> [email protected]
>>>>>=20
>>>>>> wrote:
>>>>>>>>>> Hello Frank,
>>>>>>>>>>=20
>>>>>>>>>> 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?
>>>>>>>>>>=20
>>>>>>>>>> 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,
>>>>>>>>>>=20
>>>>>>>>>> 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.
>>>>>>>>>>=20
>>>>>>>>>> CLI 1.10.0-SNAPSHOT fixes this OSGi issue (see changes.xml):
>>>>>>>>>>=20
>>>>>>>>>>> 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/
>>>>>>>>>>=20
>>>>>>>>>> This would tell us if the OSGi fix above matters.
>>>>>>>>>>=20
>>>>>>>>>> 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
>>>>>>>>>>=20
>>>>>>>>>> HTH,
>>>>>>>>>> Gary
>>>>>>>>>>=20
>>>>>>>>>> On Sun, Jun 22, 2025 at 1:39=E2=80=AFPM Frank <
>> [email protected]
>>>> .invalid>
>>>>>> wrote:
>>>>>>>>>>> Hello,
>>>>>>>>>>>=20
>>>>>>>>>>> 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
>>>>>>>>>>>=20
>>>> =
---------------------------------------------------------------------
>>>>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>>>>> For additional commands, e-mail: =
[email protected]
>>>>>>>>>>>=20
>>>>>>>>>=20
>>> =
---------------------------------------------------------------------
>>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>>=20
>>>>>>>>=20
>>>>>>>>=20
>>> =
---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: [email protected]
>>>>>>>> For additional commands, e-mail: [email protected]
>>>>>>>>=20
>>>>>>>=20
>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: [email protected]
>> <mailto:
>>>>>> [email protected]>
>>>>>>> For additional commands, e-mail: [email protected]
>>> <mailto:
>>>>>> [email protected]>
>>>>>>=20
>>>>=20
>>>> =
---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>=20
>>>>=20
>>>=20
>>=20