Unfortunately I don't see any difference if I add <manifestLocation> entry :(.
thanks,
-marina
Stuart McCulloch wrote:
2008/10/7 Marina Vatkina <[EMAIL PROTECTED]>
Stuart McCulloch wrote:
2008/10/4 Marina Vatkina <[EMAIL PROTECTED]>
I'm observing a different behavior of the felix plugin between maven
2.0.7
and 2.0.9 in generating manifest file entries when embedding dependency
from
one jar into another. The contents of the jar stays the same.
With maven 2.0.7 the following configuration correctly adds
javax.xml.rpc.handler to the Export-Package entry in the manifest file,
while with 2.0.9 the package is missing:
if it works with 2.0.7 but not with 2.0.9 (and everything else is exactly
the same)
then that suggests something has changed in the Maven dependency
algorithm.
it could be a regression in Maven - but I'd need to investigate further to
be sure...
FYI, the complete set of changes in Maven 2.0.9 is available here:
http://maven.apache.org/release-notes.html
I can't find anything that can seem realted to my problem.
and there are several updates and patches to the Maven dependency
mechanism.
have you tried enabling debug trace with "mvn -X ..." and comparing the 2
traces?
(this might then show if the dependency graph changes between 2.0.7 and
2.0.9)
I do have such outputs and they do not differ in the section that relates
to the felix plugin. Are there any other sections that I can look at?
actually I ran some local tests and there does appear to be a difference
between 2.0.7 and 2.0.9 when it comes to picking up a customized jar
manifest that's generated as part of the same build.
(there's some code inside the bundle mojo that checks the settings for
the maven-jar-plugin so it can merge any customized manifest with the
bundle generated one - this feature was required by apache commons)
looking at the GlassFish build pom for "javax.ejb" it uses jar packaging,
adds both the bundle and manifest goals, and sets the maven-jar-plugin
to use the generated manifest under "target/classes/META-INF/..."
in 2.0.7 the manifest goal runs first and generates a manifest without
the "javax.xml.rpc.handler" (because Bnd for some reason isn't taking
the Include-Resource instruction into account - possibly because we
don't actually build the bundle but just analyze the classpath...)
anyway, this generated manifest is _not_ picked up when the bundle
goal runs (possibly because of a bug in Maven wrt. detecting changes
to the build - I think this was one of the major changes in 2.0.9...) and
the final bundle has the correct manifest
in 2.0.9 the same thing happens, except this time the bundle goal can
see the generated manifest (without the "javax.xml.rpc.handler" entry)
and merges it with the generated bundle manifest - unfortunately the
entries from the custom jar manifest take priority, and so the bundle
ends up with the incorrect Export-Package entry.
getting the manifest and bundle goals aligned has been a rocky road
and it's still not an exact match as you can see - but I hope to sort
this out in the next release, as part of a push to improve usability
for now there is a simple workaround you can use to fix the problem:
<manifestLocation>${pom.build.directory}</manifestLocation>
which means the bundleplugin will write the generated manifest from
the manifest goal in a different place (not "target/classes/META-INF")
and therefore this won't be picked up when the bundle goal runs.
I've tested this locally and the build is the same on 2.0.7 and 2.0.9
HTH
thanks,
-marina
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
