You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Ernie Rael <er...@raelity.com> on 2026/08/18 04:00:08 UTC
Using NetBeans artifacts and module-info.java in a maven project
Hi all,
I'm working on a library, and I thought I'd be good forward looking
citizen and add module-info.java. I've never used module-info before. I
have pom dependencies on
<artifactId>org-openide-util</artifactId>
<artifactId>org-openide-util-lookup</artifactId>
It took a while, but I finally found
requires org.openide.util.RELEASE310;
requires org.openide.util.lookup.RELEASE310;
Running "mvn clean install" on the command line I see
[ERROR] error: the unnamed module reads package org.openide.util from
both org.openide.util.RELEASE310 and org.openide.util.lookup.RELEASE310
The error repeats several times.
Is it possible to do this? How? "Moditect" doesn't sound like much fun,
but I've only seen a reference to it, not read any documentation.
-ernie
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Ernie Rael <er...@raelity.com>.
On 26/08/20 1:51 AM, Jaroslav Tulach wrote:
> - the old habit of putting the annotation processor next to the code
> actually doesn't work with module-info well
Tried a few things. With two jars having embedded annotation processors,
using <annotationProcessorPaths> works the same, mvn clean package, with
or without module-info. Haven't tried defining a module-info for something
that embeds both runtime code and annotation processor.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Ernie Rael <er...@raelity.com>.
On 26/08/20 1:51 AM, Jaroslav Tulach wrote:
>> Putting
>> module-info back on the shelf, I like the simplicity of -proc:full.
> - hold on, module-info and annotation processors are actually deeply connected!
Yeah. That's why I finally(?) put module-info away at least until I better
understand what's going on with annotation processing. I had some confusion
because I was having problems using <annotationProcessorPaths> but that was
related to the compilation environment.
Wow, another twist. I didn't know, or had forgotten, about "uses" and
"provides"
in module-info to register annotation processors as a service
implementation.
It's way past time I get a better understanding of module-info and
annotation
processing. The notes below are helpful to clarify things. For me,
"-proc:full",
is a convenience, not a necessity; using it avoids needing to enumerate
all the
annotation processors.
While hacking into a combined jar file is easy and worked, I'm thinking that
pulling the sources into a standalone project is a better way to go. I can
even make AbstractServiceProviderProcessor sealed. ;-)
-ernie
> - the old habit of putting the annotation processor next to the code
> actually doesn't work with module-info well
> - because `requires` should reflect the runtime environment of a module
> - however when there is an annotation `Processor` then there are "two
> runtime environments"
> - one when the JAR actually runs
> - one when its annotation processor runs
> - such a "dual environment" cannot be expressed in module-info!
> - as such the modern solution is to split annotation processor into
> its own module JAR file
> - then the processor JAR `requires java.compiler` and co.
> - so it is ready for its "runtime inside of javac"
> - e.g. not the way openide-util-lookup & co. does it in NetBeans
> - however when you split the annotation processor off the API JAR,
> then `-proc:full` is no longer useful...
>
> I guess the need for `-proc:full` option is a result of some CVE
> reported to Java platform group. However even from point of
> module-info the `-proc:full` option makes no sense.
> -jt
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail:dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Jaroslav Tulach <ja...@gmail.com>.
Hello Ernie.
> Putting
> module-info back on the shelf, I like the simplicity of -proc:full.
- hold on, module-info and annotation processors are actually deeply connected!
- the old habit of putting the annotation processor next to the code
actually doesn't work with module-info well
- because `requires` should reflect the runtime environment of a module
- however when there is an annotation `Processor` then there are "two
runtime environments"
- one when the JAR actually runs
- one when its annotation processor runs
- such a "dual environment" cannot be expressed in module-info!
- as such the modern solution is to split annotation processor into
its own module JAR file
- then the processor JAR `requires java.compiler` and co.
- so it is ready for its "runtime inside of javac"
- e.g. not the way openide-util-lookup & co. does it in NetBeans
- however when you split the annotation processor off the API JAR,
then `-proc:full` is no longer useful...
I guess the need for `-proc:full` option is a result of some CVE
reported to Java platform group. However even from point of
module-info the `-proc:full` option makes no sense.
-jt
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Ernie Rael <er...@raelity.com>.
On 26/08/18 11:57 PM, Jaroslav Tulach wrote:
> FYI, on split packages: https://youtu.be/63yPccoPGDc?t=2033
Interesting. Took 3 months instead of 3 weeks. Thanks.
>
>>> Hey Jarda,
>>>> I don't see how to satisfy the JPMS requirements and still keep the
>>>> compatibility of the API. With such a choice I value compatibility
>>>> more.
>>> In this situation I'm looking for compatibility with Java;-)
> Alas, modern Java is a moving target… hard to be compatible with something that continuously tightens its constraints… especially when there is a simple switch (-cp) to turn these constraints off and live on…
> -jt
>
Yeah, starting with tight constraints then relaxing (and Yenta is a
GodSend for backwards compatibility). I believe early Sun play with
remote execution let you send and execute willy nilly; I've heard it led
to some great practical jokes.
Combining util/util-lookukp worked fine, a script to merge META-INF
works, the annotation processors work OK. Speaking of which, split
packages was easy compared to module-info and annotations. Putting
module-info back on the shelf, I like the simplicity of -proc:full.
-ernie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Jaroslav Tulach <ja...@gmail.com>.
FYI, on split packages: https://youtu.be/63yPccoPGDc?t=2033
>> Hey Jarda,
>>> I don't see how to satisfy the JPMS requirements and still keep the
>>> compatibility of the API. With such a choice I value compatibility
>>> more.
>> In this situation I'm looking for compatibility with Java;-)
Alas, modern Java is a moving target… hard to be compatible with something that continuously tightens its constraints… especially when there is a simple switch (-cp) to turn these constraints off and live on…
-jt
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
Am Sonntag, dem 23.08.2026 um 08:07 +0000 schrieb Andrew Goh via dev:
> I don't want to start a flame war, but I think open source programmers are not too helpful these days. Perhaps you can show me the right thread.
for the "right thread part": You replied to an email with subject
"Using NetBeans artifacts and module-info.java in a maven project" and
asked about download help. That is called of topic as the topic of this
thread is about the said subject. You can open your own thread by just
sending an email to the mailinglist with a subject that describes the
issue you want to write about.
for the "not helpful" part: Literally the first entry of the page
"Downloading Apache NetBeans 31" that Laszlo linked is the right
answer. Right in this case, NetBeans without a bundled JDK.
The JDK bundles are provided by third parties as written on the
download page and are convenience packages.
So not sure what you expect?
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Andrew Goh via dev <de...@netbeans.apache.org>.
I don't want to start a flame war, but I think open source programmers are not too helpful these days. Perhaps you can show me the right thread.
On Sunday, 23 August 2026 at 02:20:31 pm SGT, Laszlo Kishalmi <la...@gmail.com> wrote:
On 8/18/26 18:29, Andrew Goh via dev wrote:
> Hi, I will like to make a request to the NB development team. Give users the option of down loading NB IDE minus the Java SDK. I saw NB 31 coming with JDK 26, but I still want to keep Java 25 LTS.
> - Andrew
I think you are off-topic on this thread.
It is always possible to download NetBeans without the JDK using it's
binary zip file. It's practically the first link on the page:
https://netbeans.apache.org/front/main/download/nb31/
It is also stated that the RunTime JDK does not limit the range of JDK-s
your project can use.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Laszlo Kishalmi <la...@gmail.com>.
On 8/18/26 18:29, Andrew Goh via dev wrote:
> Hi, I will like to make a request to the NB development team. Give users the option of down loading NB IDE minus the Java SDK. I saw NB 31 coming with JDK 26, but I still want to keep Java 25 LTS.
> - Andrew
I think you are off-topic on this thread.
It is always possible to download NetBeans without the JDK using it's
binary zip file. It's practically the first link on the page:
https://netbeans.apache.org/front/main/download/nb31/
It is also stated that the RunTime JDK does not limit the range of JDK-s
your project can use.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Andrew Goh via dev <de...@netbeans.apache.org>.
Hi, I will like to make a request to the NB development team. Give users the option of down loading NB IDE minus the Java SDK. I saw NB 31 coming with JDK 26, but I still want to keep Java 25 LTS.
- Andrew
On Wednesday, 19 August 2026 at 03:53:02 am SGT, Michael Bien <mb...@gmail.com> wrote:
On 8/18/26 20:42, Ernie Rael wrote:
> Hey Jarda,
>> I don't see how to satisfy the JPMS requirements and still keep the
>> compatibility of the API. With such a choice I value compatibility
>> more.
> In this situation I'm looking for compatibility with Java;-)
>
> I suppose, to achieve my goal, I can make a chubby jar file with
you could try to leave one side of the split package on the cp and only
depend on the other side. Be ready to do that several times since this
is not going to be the only split package most likely.
(I never used java modules in NB applications so I don't know if there
would be followup issues additionally to split packages - you would
essentially run two module systems)
you can also patch one java module into another module, making them one
module - this would merge split packages. Depend on one module and the
other becomes "--patch-module <first module>=<path>". (Again, i never
tried that, if this overwrites NB specific module config this will
become a problem)
not saying you should do any of that, you could also stick to cp which
is known to work.
-mbien
> the extracted classes from the util and util-lookup jar files. It's
> been a while since I hacked together a jar file. If it wasn't for
> wanting WeakListeners...
>
> I suppose I could investigate moditect, but mucking with jar files
> seems simpler. Since the idea is more to play with module-info and
> not urgent, this can percolate for now; and I've certainly learned
> something about module-info.
>
> -ernie
>
> On 26/08/17 10:14 PM, Jaroslav Tulach wrote:
>> Hello Ernie.
>>
>>> reads package org.openide.util from
>> both org.openide.util.RELEASE310 and org.openide.util.lookup.RELEASE310
>>
>> I believe you are hitting limitation of "split packages". When I
>> modularized monolithic openide.jar into pieces I wanted to keep 100%
>> compatibility. Hence I included the same package into multiple JAR
>> files. That's OK for NetBeans Runtime Container as well as OSGi.
>> However JPMS doesn't allow that.
>>
>> I don't see how to satisfy the JPMS requirements and still keep the
>> compatibility of the API. With such a choice I value compatibility
>> more.
>>
>> -jt
>>
>> PS: I am also trying to use JPMS from time to time, but there are
>> numerous problems all over (testing being one of them
>> https://lists.apache.org/thread/f5st2t0wspbdmjt6v5ojobzqpl7cjk9n).
>> Fixing the split packages wouldn't be the end of the endeavor.
>>
>> út 18. 8. 2026 v 6:00 odesílatel Ernie Rael<er...@raelity.com> napsal:
>>
>>> Hi all,
>>>
>>> I'm working on a library, and I thought I'd be good forward looking
>>> citizen and add module-info.java. I've never used module-info before. I
>>> have pom dependencies on
>>>
>>> <artifactId>org-openide-util</artifactId>
>>> <artifactId>org-openide-util-lookup</artifactId>
>>>
>>> It took a while, but I finally found
>>>
>>> requires org.openide.util.RELEASE310;
>>> requires org.openide.util.lookup.RELEASE310;
>>>
>>> Running "mvn clean install" on the command line I see
>>> [ERROR] error: the unnamed module reads package org.openide.util from
>>> both org.openide.util.RELEASE310 and org.openide.util.lookup.RELEASE310
>>> The error repeats several times.
>>>
>>> Is it possible to do this? How? "Moditect" doesn't sound like much fun,
>>> but I've only seen a reference to it, not read any documentation.
>>>
>>> -ernie
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail:dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Ernie Rael <er...@raelity.com>.
On 26/08/18 12:52 PM, Michael Bien wrote:
> never used java modules in NB applications
To be clear, this is for a plain old java library that uses openide-util
and openide-util-lookup. The complexities you speak of, e.g. overwrites
NB specific module config, do not come into play.
The chubby jar increasingly seems like the simplest solution. A script
to extract the class files, toss META-INF, add MANIFEST.MF, jar -c ...
Use RELEASE290 for jdk-17 compatibility.
-ernie
> On 8/18/26 20:42, Ernie Rael wrote:
>> Hey Jarda,
>>> I don't see how to satisfy the JPMS requirements and still keep the
>>> compatibility of the API. With such a choice I value compatibility
>>> more.
>> In this situation I'm looking for compatibility with Java;-)
>>
>> I suppose, to achieve my goal, I can make a chubby jar file with
> you could try to leave one side of the split package on the cp and only
> depend on the other side. Be ready to do that several times since this
> is not going to be the only split package most likely.
>
> (I never used java modules in NB applications so I don't know if there
> would be followup issues additionally to split packages - you would
> essentially run two module systems)
>
> you can also patch one java module into another module, making them one
> module - this would merge split packages. Depend on one module and the
> other becomes "--patch-module <first module>=<path>". (Again, i never
> tried that, if this overwrites NB specific module config this will
> become a problem)
>
> not saying you should do any of that, you could also stick to cp which
> is known to work.
>
> -mbien
>
>
>> the extracted classes from the util and util-lookup jar files. It's
>> been a while since I hacked together a jar file. If it wasn't for
>> wanting WeakListeners...
>>
>> I suppose I could investigate moditect, but mucking with jar files
>> seems simpler. Since the idea is more to play with module-info and
>> not urgent, this can percolate for now; and I've certainly learned
>> something about module-info.
>>
>> -ernie
>>
>> On 26/08/17 10:14 PM, Jaroslav Tulach wrote:
>>> Hello Ernie.
>>>
>>>> reads package org.openide.util from
>>> both org.openide.util.RELEASE310 and org.openide.util.lookup.RELEASE310
>>>
>>> I believe you are hitting limitation of "split packages". When I
>>> modularized monolithic openide.jar into pieces I wanted to keep 100%
>>> compatibility. Hence I included the same package into multiple JAR
>>> files. That's OK for NetBeans Runtime Container as well as OSGi.
>>> However JPMS doesn't allow that.
>>>
>>> I don't see how to satisfy the JPMS requirements and still keep the
>>> compatibility of the API. With such a choice I value compatibility
>>> more.
>>>
>>> -jt
>>>
>>> PS: I am also trying to use JPMS from time to time, but there are
>>> numerous problems all over (testing being one of them
>>> https://lists.apache.org/thread/f5st2t0wspbdmjt6v5ojobzqpl7cjk9n).
>>> Fixing the split packages wouldn't be the end of the endeavor.
>>>
>>> út 18. 8. 2026 v 6:00 odesílatel Ernie Rael<er...@raelity.com> napsal:
>>>
>>>> Hi all,
>>>>
>>>> I'm working on a library, and I thought I'd be good forward looking
>>>> citizen and add module-info.java. I've never used module-info before. I
>>>> have pom dependencies on
>>>>
>>>> <artifactId>org-openide-util</artifactId>
>>>> <artifactId>org-openide-util-lookup</artifactId>
>>>>
>>>> It took a while, but I finally found
>>>>
>>>> requires org.openide.util.RELEASE310;
>>>> requires org.openide.util.lookup.RELEASE310;
>>>>
>>>> Running "mvn clean install" on the command line I see
>>>> [ERROR] error: the unnamed module reads package org.openide.util from
>>>> both org.openide.util.RELEASE310 and org.openide.util.lookup.RELEASE310
>>>> The error repeats several times.
>>>>
>>>> Is it possible to do this? How? "Moditect" doesn't sound like much fun,
>>>> but I've only seen a reference to it, not read any documentation.
>>>>
>>>> -ernie
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:dev-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail:dev-help@netbeans.apache.org
>>>
>>> For further information about the NetBeans mailing lists, visit:
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>
>>>
>>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail: dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Michael Bien <mb...@gmail.com>.
On 8/18/26 20:42, Ernie Rael wrote:
> Hey Jarda,
>> I don't see how to satisfy the JPMS requirements and still keep the
>> compatibility of the API. With such a choice I value compatibility
>> more.
> In this situation I'm looking for compatibility with Java;-)
>
> I suppose, to achieve my goal, I can make a chubby jar file with
you could try to leave one side of the split package on the cp and only
depend on the other side. Be ready to do that several times since this
is not going to be the only split package most likely.
(I never used java modules in NB applications so I don't know if there
would be followup issues additionally to split packages - you would
essentially run two module systems)
you can also patch one java module into another module, making them one
module - this would merge split packages. Depend on one module and the
other becomes "--patch-module <first module>=<path>". (Again, i never
tried that, if this overwrites NB specific module config this will
become a problem)
not saying you should do any of that, you could also stick to cp which
is known to work.
-mbien
> the extracted classes from the util and util-lookup jar files. It's
> been a while since I hacked together a jar file. If it wasn't for
> wanting WeakListeners...
>
> I suppose I could investigate moditect, but mucking with jar files
> seems simpler. Since the idea is more to play with module-info and
> not urgent, this can percolate for now; and I've certainly learned
> something about module-info.
>
> -ernie
>
> On 26/08/17 10:14 PM, Jaroslav Tulach wrote:
>> Hello Ernie.
>>
>>> reads package org.openide.util from
>> both org.openide.util.RELEASE310 and org.openide.util.lookup.RELEASE310
>>
>> I believe you are hitting limitation of "split packages". When I
>> modularized monolithic openide.jar into pieces I wanted to keep 100%
>> compatibility. Hence I included the same package into multiple JAR
>> files. That's OK for NetBeans Runtime Container as well as OSGi.
>> However JPMS doesn't allow that.
>>
>> I don't see how to satisfy the JPMS requirements and still keep the
>> compatibility of the API. With such a choice I value compatibility
>> more.
>>
>> -jt
>>
>> PS: I am also trying to use JPMS from time to time, but there are
>> numerous problems all over (testing being one of them
>> https://lists.apache.org/thread/f5st2t0wspbdmjt6v5ojobzqpl7cjk9n).
>> Fixing the split packages wouldn't be the end of the endeavor.
>>
>> út 18. 8. 2026 v 6:00 odesílatel Ernie Rael<er...@raelity.com> napsal:
>>
>>> Hi all,
>>>
>>> I'm working on a library, and I thought I'd be good forward looking
>>> citizen and add module-info.java. I've never used module-info before. I
>>> have pom dependencies on
>>>
>>> <artifactId>org-openide-util</artifactId>
>>> <artifactId>org-openide-util-lookup</artifactId>
>>>
>>> It took a while, but I finally found
>>>
>>> requires org.openide.util.RELEASE310;
>>> requires org.openide.util.lookup.RELEASE310;
>>>
>>> Running "mvn clean install" on the command line I see
>>> [ERROR] error: the unnamed module reads package org.openide.util from
>>> both org.openide.util.RELEASE310 and org.openide.util.lookup.RELEASE310
>>> The error repeats several times.
>>>
>>> Is it possible to do this? How? "Moditect" doesn't sound like much fun,
>>> but I've only seen a reference to it, not read any documentation.
>>>
>>> -ernie
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail:dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Matthias Bläsing <mb...@doppel-helix.eu>.
Hi,
Am Dienstag, dem 18.08.2026 um 11:42 -0700 schrieb Ernie Rael:
> > I don't see how to satisfy the JPMS requirements and still keep the
> > compatibility of the API. With such a choice I value compatibility
> > more.
> In this situation I'm looking for compatibility with Java;-)
the classpath is still there and I don't see it going away soon. So of
course the NB modules are compatible with Java (however you define
Java).
Greetings
Matthias
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Ernie Rael <er...@raelity.com>.
Hey Jarda,
> I don't see how to satisfy the JPMS requirements and still keep the
> compatibility of the API. With such a choice I value compatibility
> more.
In this situation I'm looking for compatibility with Java;-)
I suppose, to achieve my goal, I can make a chubby jar file with
the extracted classes from the util and util-lookup jar files. It's
been a while since I hacked together a jar file. If it wasn't for
wanting WeakListeners...
I suppose I could investigate moditect, but mucking with jar files
seems simpler. Since the idea is more to play with module-info and
not urgent, this can percolate for now; and I've certainly learned
something about module-info.
-ernie
On 26/08/17 10:14 PM, Jaroslav Tulach wrote:
> Hello Ernie.
>
>> reads package org.openide.util from
> both org.openide.util.RELEASE310 and org.openide.util.lookup.RELEASE310
>
> I believe you are hitting limitation of "split packages". When I
> modularized monolithic openide.jar into pieces I wanted to keep 100%
> compatibility. Hence I included the same package into multiple JAR
> files. That's OK for NetBeans Runtime Container as well as OSGi.
> However JPMS doesn't allow that.
>
> I don't see how to satisfy the JPMS requirements and still keep the
> compatibility of the API. With such a choice I value compatibility
> more.
>
> -jt
>
> PS: I am also trying to use JPMS from time to time, but there are
> numerous problems all over (testing being one of them
> https://lists.apache.org/thread/f5st2t0wspbdmjt6v5ojobzqpl7cjk9n).
> Fixing the split packages wouldn't be the end of the endeavor.
>
> út 18. 8. 2026 v 6:00 odesílatel Ernie Rael<er...@raelity.com> napsal:
>
>> Hi all,
>>
>> I'm working on a library, and I thought I'd be good forward looking
>> citizen and add module-info.java. I've never used module-info before. I
>> have pom dependencies on
>>
>> <artifactId>org-openide-util</artifactId>
>> <artifactId>org-openide-util-lookup</artifactId>
>>
>> It took a while, but I finally found
>>
>> requires org.openide.util.RELEASE310;
>> requires org.openide.util.lookup.RELEASE310;
>>
>> Running "mvn clean install" on the command line I see
>> [ERROR] error: the unnamed module reads package org.openide.util from
>> both org.openide.util.RELEASE310 and org.openide.util.lookup.RELEASE310
>> The error repeats several times.
>>
>> Is it possible to do this? How? "Moditect" doesn't sound like much fun,
>> but I've only seen a reference to it, not read any documentation.
>>
>> -ernie
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:dev-unsubscribe@netbeans.apache.org
> For additional commands, e-mail:dev-help@netbeans.apache.org
>
> For further information about the NetBeans mailing lists, visit:
> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>
>
>
Re: Using NetBeans artifacts and module-info.java in a maven project
Posted by Jaroslav Tulach <ja...@gmail.com>.
Hello Ernie.
> reads package org.openide.util from
both org.openide.util.RELEASE310 and org.openide.util.lookup.RELEASE310
I believe you are hitting limitation of "split packages". When I
modularized monolithic openide.jar into pieces I wanted to keep 100%
compatibility. Hence I included the same package into multiple JAR
files. That's OK for NetBeans Runtime Container as well as OSGi.
However JPMS doesn't allow that.
I don't see how to satisfy the JPMS requirements and still keep the
compatibility of the API. With such a choice I value compatibility
more.
-jt
PS: I am also trying to use JPMS from time to time, but there are
numerous problems all over (testing being one of them
https://lists.apache.org/thread/f5st2t0wspbdmjt6v5ojobzqpl7cjk9n).
Fixing the split packages wouldn't be the end of the endeavor.
út 18. 8. 2026 v 6:00 odesílatel Ernie Rael <er...@raelity.com> napsal:
>
> Hi all,
>
> I'm working on a library, and I thought I'd be good forward looking
> citizen and add module-info.java. I've never used module-info before. I
> have pom dependencies on
>
> <artifactId>org-openide-util</artifactId>
> <artifactId>org-openide-util-lookup</artifactId>
>
> It took a while, but I finally found
>
> requires org.openide.util.RELEASE310;
> requires org.openide.util.lookup.RELEASE310;
>
> Running "mvn clean install" on the command line I see
> [ERROR] error: the unnamed module reads package org.openide.util from
> both org.openide.util.RELEASE310 and org.openide.util.lookup.RELEASE310
> The error repeats several times.
>
> Is it possible to do this? How? "Moditect" doesn't sound like much fun,
> but I've only seen a reference to it, not read any documentation.
>
> -ernie
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists