Re: Strange Behavior with Commons-CLI

Kolja <[email protected]> Tue, 24 Jun 2025 09:56:42 +0200
Newsgroups gmane.comp.jakarta.commons.user
Message-ID <[email protected]>
Hi,

see also=20
https://github.com/eclipse-jdt/eclipse.jdt.core/issues/2495#issuecomment-2=
254297050

The problem is that the commons-cli jar misses directory entries for=20
'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=20
directories, does not find them and then reverts to deriving the=20
modulename from the filename.
[https://github.com/eclipse-jdt/eclipse.jdt.core/blob/ed787f542d5509ba226f=
0b8b06982d61e81b4622/org.eclipse.jdt.core/model/org/eclipse/jdt/internal/c=
ore/builder/ClasspathMultiReleaseJar.java#L83-L85]

Hopefully=C2=A0 someone can fix that for commons-cli and maybe check other=
=20
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]> wr=
ote:
>
>> BTW, Just opened the project in IntelliJ.  Maven POM is unchanged excep=
t
>> to up the Commons CLI version to 1.9.0.  No problems with module detect=
ion.
>> 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 <[email protected]=
om.invalid
>> <mailto:[email protected]>> wrote:
>>>> I added your snapshot repo, changed my pom.xml and verified in Eclips=
e
>> 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 a=
s 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 clas=
s 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@g=
mail.com>
>> wrote:
>>>>>> Hello Frank,
>>>>>>
>>>>>> Are you saying that no matter what version of Commons CLI you use a=
nd
>>>>>> then build from the command line with Maven, all is well?
>>>>>>
>>>>>> If the above is true, then this suggests one of two things: Somethi=
ng
>>>>>> 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 sinc=
e
>>>>>> 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 fr=
om
>>>>>> 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 Comm=
ons
>>>>>> CLI using OSGi in the same way as Commons Compress in the test pack=
age
>>>>>> org.apache.commons.compress.osgi
>>>>>>
>>>>>> HTH,
>>>>>> Gary
>>>>>>
>>>>>> On Sun, Jun 22, 2025 at 1:39=E2=80=AFPM Frank <software_frank@runbo=
x.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 thi=
ng
>> is that if I drop back to version 1.6.0, the error disappears.  The com=
mand
>> line build and the IDE build both work.  Any version after that produce=
s
>> 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
>>>>>>> ------------------------------------------------------------------=
=2D--
>>>>>>> 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]>
>>