NB Application build by maven and 'may be multiply loaded by modules'

[Kutschera Peter-2]

Hello out there!

I just got an 'interesting' problem when running my maven-generated NB Application.

I found a lot of information about this problem and NOT maven-based applications on the internet, but not for maven-based projects.


My problem is as follows:

There are two mvn artifacts x-api and x-impl, where x-impl depends on x-api. Both of them are outside netbeans.

Now I have a NB RCP Application with two modules:
 xfilesupport (depending on x-impl)
 xfileviewer  (depending on x-impl)

When starting the application I get a lot of warnings for x-impl, x-api and all artefacts x-impl and x-api are depending on.

WARNUNG [org.netbeans.core.startup.NbEvents]: The extension ..x-api-1.0-SNAPSHOT.jar may be multiply loaded by modules: [...-xfilesupport.jar, ...-xfileviewer.jar]; see: http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/classpath.html#class-path

It seems to me this link is non-maven specific, I am not sure if and how I can use this in information.

The interesting thing is that both, xfilesupport and xfileviewer depends on e.g. org-openide-util but there are no warnings about the org-openide-util artefact.

I tried the following:
 Since xfileviewer depends on xfilesupport I removed the direct dependency to x-impl in pom.xml.
 There is NO dependency to x-api in the pom.xml!
 This results in
Adding on module's Class-Path:
    ..x-api:jar:1.0-SNAPSHOT
    .. some artefacts x-api depends on ..
Private classes referenced from module: [...x_impl.SomeClassImpl]
[ERROR]Project depends on packages not accessible at runtime in module ...xfilesupport:jar:1.0-SNAPSHOT

So what can I do?
* Should I add the x-impl and x-api packages as public packages to xfilesupport?
* I already tried to move all dependencies to external artifacts in one nbm "extArtifacts" and depending on this in my other nbms, but this did not help, but maybe IU did something wrong, I am sot sure about this.
* And I don't want to put all of my code within 1 (one) nbm, but this seems to be the next thing to try on monday morning :-(


Any help will be welcome.

Thanks in advance and have a nice weekend
 Peter Kutschera

[Jesse Glick]

Kutschera Peter wrote:
> There are two mvn artifacts x-api and x-impl, where x-impl depends on x-api.. Both of them are outside netbeans.
>
> Now I have a NB RCP Application with two modules:
>  xfilesupport (depending on x-impl)
>  xfileviewer  (depending on x-impl)
>
> WARNUNG: The extension ..x-api-1.0-SNAPSHOT.jar may be multiply loaded by modules: [...-xfilesupport.jar, ...-xfileviewer.jar]

Meaning both of these modules actually bundled x-api-1.0-SNAPSHOT.jar - not what you wanted to do. Probably you meant to make a wrapper module for x-api and x-impl, or
one wrapper module for each, and then depend on these modules from xfilesupport and xfileviewer.

[mkleint-3]

Kutschera Peter wrote:

> Hello out there!
>
> I just got an 'interesting' problem when running my maven-generated NB Application.
>
> I found a lot of information about this problem and NOT maven-based applications on the internet, but not for maven-based projects.
>
>
> My problem is as follows:
>
> There are two mvn artifacts x-api and x-impl, where x-impl depends on x-api. Both of them are outside netbeans.
>
> Now I have a NB RCP Application with two modules:
>  xfilesupport (depending on x-impl)
>  xfileviewer  (depending on x-impl)
>
> When starting the application I get a lot of warnings for x-impl, x-api and all artefacts x-impl and x-api are depending on.
>
> WARNUNG [org.netbeans.core.startup.NbEvents]: The extension ..x-api-1.0-SNAPSHOT.jar may be multiply loaded by modules: [...-xfilesupport.jar, ...-xfileviewer.jar]; see: http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/classpath.html#class-path
>
> It seems to me this link is non-maven specific, I am not sure if and how I can use this in information.
>
> The interesting thing is that both, xfilesupport and xfileviewer depends on e.g. org-openide-util but there are no warnings about the org-openide-util artefact.
>
> I tried the following:
>  Since xfileviewer depends on xfilesupport I removed the direct dependency to x-impl in pom.xml.
>  There is NO dependency to x-api in the pom.xml!
>  This results in
> Adding on module's Class-Path:
>     ..x-api:jar:1.0-SNAPSHOT
>     .. some artefacts x-api depends on ..
> Private classes referenced from module: [...x_impl.SomeClassImpl]
> [ERROR]Project depends on packages not accessible at runtime in module ...xfilesupport:jar:1.0-SNAPSHOT
>  

That's the core of the problem. If you depend on a module, that module
need to expose public packages. Even for external classpath items it
ships with.
So either xfilesupport needs to expose the packages from the x-impl, or
have a separate module for the x-impl binary that will expose the api
packages. In either case the api packages config is done as part of the
nbm-maven-plugin configuration.
please check the Maven Dependency vs NetBeans runtime dependency section
in http://mojo.codehaus.org/nbm-maven-plugin/

Milos

> So what can I do?
> * Should I add the x-impl and x-api packages as public packages to xfilesupport?
> * I already tried to move all dependencies to external artifacts in one nbm "extArtifacts" and depending on this in my other nbms, but this did not help, but maybe IU did something wrong, I am sot sure about this.
> * And I don't want to put all of my code within 1 (one) nbm, but this seems to be the next thing to try on monday morning :-(
>
>
> Any help will be welcome.
>
> Thanks in advance and have a nice weekend
>  Peter Kutschera
>
>
>  

[Kutschera Peter-2]

Hello Milos!

Thanks for your answer - I got it running the extArtifacts-module way.
This solution will be good enough for short time usage.

But if I understood this correctly writing a new module for an existing
application (Which should be possible to the users of my application) would
need knowledge about the implementation details (= libraries already used by
all other modules of the application).

This is relative strait forward for application specific things (x-api and
x-impl in this case, which are explicitly exposed), but by transitive
dependencies some things like special swing elements (JCalendar in my case)
are used.

The JCalendar is not exposed as public package.

If someone writes a new module and is also using JCalendar, what will
happen?
 He can not use the JCalendar already in the classpath since this package is
not exposed.
 He can not add the JCalendar since he will run in the classpath-problem.

Is this correct?
Are there any "best practice" documents out there?


BTW: NB 6.8Beta using moduleArchetype 1.2 generated a
nbm-plugin-configuration version 3.1 with module.xml (which is stated as
obsolete for version 3.0+ and contains only some license information).
I added some
<publicPackages>
 <publicPackage>...x_api</publicPackage>
 <publicPackage>...x_impl</publicPackage>
 More packages...
</publicPackages>
lines, which I could not found on http://mojo.codehaus.org/nbm-maven-plugin/
but by reading some pom.xml from some open source projects.
(There is only a short notice in the last paragraph of
http://mojo.codehaus.org/nbm-maven-plugin/2630upgrade.html)

Is this the correct way to expose the public packages?


Well, again, thanks for your time and answer
 Peter





-----Ursprüngliche Nachricht-----
Von: Milos.Kleint@... [mailto:Milos.Kleint@...]
Gesendet: Montag, 02. November 2009 07:59
An: dev@...
Betreff: Re: [openide-dev] NB Application build by maven and 'may be
multiply loaded by modules'

Kutschera Peter wrote:
> Hello out there!
>
> I just got an 'interesting' problem when running my maven-generated NB
Application.
>
> I found a lot of information about this problem and NOT maven-based
applications on the internet, but not for maven-based projects.
>
>
> My problem is as follows:
>
> There are two mvn artifacts x-api and x-impl, where x-impl depends on
x-api. Both of them are outside netbeans.
>
> Now I have a NB RCP Application with two modules:
>  xfilesupport (depending on x-impl)
>  xfileviewer  (depending on x-impl)
>
> When starting the application I get a lot of warnings for x-impl, x-api
and all artefacts x-impl and x-api are depending on.
>
> WARNUNG [org.netbeans.core.startup.NbEvents]: The extension
..x-api-1.0-SNAPSHOT.jar may be multiply loaded by modules:
[...-xfilesupport.jar, ...-xfileviewer.jar]; see:
http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide
/modules/doc-files/classpath.html#class-path
>
> It seems to me this link is non-maven specific, I am not sure if and how I
can use this in information.
>
> The interesting thing is that both, xfilesupport and xfileviewer depends
on e.g. org-openide-util but there are no warnings about the
org-openide-util artefact.
>
> I tried the following:
>  Since xfileviewer depends on xfilesupport I removed the direct dependency
to x-impl in pom.xml.
>  There is NO dependency to x-api in the pom.xml!
>  This results in
> Adding on module's Class-Path:
>     ..x-api:jar:1.0-SNAPSHOT
>     .. some artefacts x-api depends on ..
> Private classes referenced from module: [...x_impl.SomeClassImpl]
> [ERROR]Project depends on packages not accessible at runtime in module
...xfilesupport:jar:1.0-SNAPSHOT
>  
That's the core of the problem. If you depend on a module, that module
need to expose public packages. Even for external classpath items it
ships with.
So either xfilesupport needs to expose the packages from the x-impl, or
have a separate module for the x-impl binary that will expose the api
packages. In either case the api packages config is done as part of the
nbm-maven-plugin configuration.
please check the Maven Dependency vs NetBeans runtime dependency section
in http://mojo.codehaus.org/nbm-maven-plugin/

Milos


> So what can I do?
> * Should I add the x-impl and x-api packages as public packages to
xfilesupport?
> * I already tried to move all dependencies to external artifacts in one
nbm "extArtifacts" and depending on this in my other nbms, but this did not
help, but maybe IU did something wrong, I am sot sure about this.
> * And I don't want to put all of my code within 1 (one) nbm, but this
seems to be the next thing to try on monday morning :-(
>
>
> Any help will be welcome.
>
> Thanks in advance and have a nice weekend
>  Peter Kutschera
>
>
>  

[mkleint-3]

Kutschera Peter wrote:

> Hello Milos!
>
> Thanks for your answer - I got it running the extArtifacts-module way.
> This solution will be good enough for short time usage.
>
> But if I understood this correctly writing a new module for an existing
> application (Which should be possible to the users of my application) would
> need knowledge about the implementation details (= libraries already used by
> all other modules of the application).
>  

no necessarily. The first warning you got:

WARNUNG [org.netbeans.core.startup.NbEvents]: The extension ..x-api-1.0-SNAPSHOT.jar may be multiply loaded by modules: [...-xfilesupport.jar, ...-xfileviewer.jar]; see: http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide/modules/doc-files/classpath.html#class-path

states that one physical jar file is being used by 2 modules. That in
general is not that much of a problem, given
1. both point to the same binary (most probably they do for maven
dependencies which have version encoded) and
2. none is exposing them as public API, only keeps them private. (eg if
you have jar A embedded in module AA and AB with exposed packages, then
if module BC depends both on AA and AB, you get a problem)
3. the classes in library jar don't do some weird classpath discovery
magic..
unlike maven dependencies, netbeans module runtime dependencies are not
transitive.

Please note that you might get a problem with manipulating the module
system though. Like removing/updating modules. the upgrading of module
AA along with upgrading the library A to new version, might result in
deleting the old A and adding new version of A binary. Leaving AB module
with no A it knows about..

I guess we should fix the problem by appending the originating module to
the ext/A.jar -> ext/AA/A.jar vs ext/AB/A.jar in the Class-Path manifest
entry. Please file an issue with reagrd to the problem under:
http://jira.codehaus.org/browse/MNBMODULE

thanks.

> This is relative strait forward for application specific things (x-api and
> x-impl in this case, which are explicitly exposed), but by transitive
> dependencies some things like special swing elements (JCalendar in my case)
> are used.
>
> The JCalendar is not exposed as public package.
>
> If someone writes a new module and is also using JCalendar, what will
> happen?
>  

to get any kind of problem they would have to put their module in the
same cluster and have the same name of the jcalendar jar binary on their
Class-Path:


>  He can not use the JCalendar already in the classpath since this package is
> not exposed.
>  He can not add the JCalendar since he will run in the classpath-problem.
>  
Not in most cases as described above.

> Is this correct?
> Are there any "best practice" documents out there?
>
>
> BTW: NB 6.8Beta using moduleArchetype 1.2 generated a
> nbm-plugin-configuration version 3.1 with module.xml (which is stated as
> obsolete for version 3.0+ and contains only some license information).
> I added some
> <publicPackages>
>  <publicPackage>...x_api</publicPackage>
>  <publicPackage>...x_impl</publicPackage>
>  More packages...
> </publicPackages>
> lines, which I could not found on http://mojo.codehaus.org/nbm-maven-plugin/
> but by reading some pom.xml from some open source projects.
> (There is only a short notice in the last paragraph of
> http://mojo.codehaus.org/nbm-maven-plugin/2630upgrade.html)
>
> Is this the correct way to expose the public packages?
>  

I suppose so. The ultimate check is to examine the resulting module
jar's generated manifest entries.


Milos

>
> Well, again, thanks for your time and answer
>  Peter
>
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Milos.Kleint@... [mailto:Milos.Kleint@...]
> Gesendet: Montag, 02. November 2009 07:59
> An: dev@...
> Betreff: Re: [openide-dev] NB Application build by maven and 'may be
> multiply loaded by modules'
>
> Kutschera Peter wrote:
>  
>> Hello out there!
>>
>> I just got an 'interesting' problem when running my maven-generated NB
>>    
> Application.
>  
>> I found a lot of information about this problem and NOT maven-based
>>    
> applications on the internet, but not for maven-based projects.
>  
>> My problem is as follows:
>>
>> There are two mvn artifacts x-api and x-impl, where x-impl depends on
>>    
> x-api. Both of them are outside netbeans.
>  
>> Now I have a NB RCP Application with two modules:
>>  xfilesupport (depending on x-impl)
>>  xfileviewer  (depending on x-impl)
>>
>> When starting the application I get a lot of warnings for x-impl, x-api
>>    
> and all artefacts x-impl and x-api are depending on.
>  
>> WARNUNG [org.netbeans.core.startup.NbEvents]: The extension
>>    
> ..x-api-1.0-SNAPSHOT.jar may be multiply loaded by modules:
> [...-xfilesupport.jar, ...-xfileviewer.jar]; see:
> http://www.netbeans.org/download/dev/javadoc/org-openide-modules/org/openide
> /modules/doc-files/classpath.html#class-path
>  
>> It seems to me this link is non-maven specific, I am not sure if and how I
>>    
> can use this in information.
>  
>> The interesting thing is that both, xfilesupport and xfileviewer depends
>>    
> on e.g. org-openide-util but there are no warnings about the
> org-openide-util artefact.
>  
>> I tried the following:
>>  Since xfileviewer depends on xfilesupport I removed the direct dependency
>>    
> to x-impl in pom.xml.
>  
>>  There is NO dependency to x-api in the pom.xml!
>>  This results in
>> Adding on module's Class-Path:
>>     ..x-api:jar:1.0-SNAPSHOT
>>     .. some artefacts x-api depends on ..
>> Private classes referenced from module: [...x_impl.SomeClassImpl]
>> [ERROR]Project depends on packages not accessible at runtime in module
>>    
> ...xfilesupport:jar:1.0-SNAPSHOT
>  
>>  
>>    
> That's the core of the problem. If you depend on a module, that module
> need to expose public packages. Even for external classpath items it
> ships with.
> So either xfilesupport needs to expose the packages from the x-impl, or
> have a separate module for the x-impl binary that will expose the api
> packages. In either case the api packages config is done as part of the
> nbm-maven-plugin configuration.
> please check the Maven Dependency vs NetBeans runtime dependency section
> in http://mojo.codehaus.org/nbm-maven-plugin/
>
> Milos
>
>
>  
>> So what can I do?
>> * Should I add the x-impl and x-api packages as public packages to
>>    
> xfilesupport?
>  
>> * I already tried to move all dependencies to external artifacts in one
>>    
> nbm "extArtifacts" and depending on this in my other nbms, but this did not
> help, but maybe IU did something wrong, I am sot sure about this.
>  
>> * And I don't want to put all of my code within 1 (one) nbm, but this
>>    
> seems to be the next thing to try on monday morning :-(
>  
>> Any help will be welcome.
>>
>> Thanks in advance and have a nice weekend
>>  Peter Kutschera
>>
>>
>>  
>>    
>
>