Posted via mailing list.
|Posted: Mon Nov 02, 2009 8:23 am Post subject: AW: NB Application build by maven and 'may be multiply loaded by modules'
|Kutschera Peter wrote:
no necessarily. The first warning you got:
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).
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
unlike maven dependencies, netbeans module runtime dependencies are not
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:
to get any kind of problem they would have to put their module in the
|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)
The JCalendar is not exposed as public package.
If someone writes a new module and is also using JCalendar, what will
same cluster and have the same name of the jcalendar jar binary on their
Not in most cases as described above.
|He can not use the JCalendar already in the classpath since this package is
He can not add the JCalendar since he will run in the classpath-problem.
I suppose so. The ultimate check is to examine the resulting module
|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
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
Is this the correct way to expose the public packages?
jar's generated manifest entries.
Well, again, thanks for your time and answer
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You can attach files in this forum
You can download files in this forum