Allow updation of an artifact's manifest at the final stage
-----------------------------------------------------------
Key: FELIX-3018
URL: https://issues.apache.org/jira/browse/FELIX-3018
Project: Felix
Issue Type: New Feature
Components: Maven Bundle Plugin
Affects Versions: maven-bundle-plugin-2.3.4
Reporter: Sahoo
Please take a look at the discussion in FELIX-1571 that triggered this RFE to
be filed.
There are at least two predominant approaches to generating OSGi bundles using
maven-bundle-plugin:
a) Use packaging type like war, jar, ejb, etc., configure bundle plugin's
manifest goal to be run in an appropriate phase like process-classes and
configure the maven-archiver to use bundle plugin generated MANIFEST.MF in the
final artifact.
b) Use packaging type bundle so that bundle plugin is responsible for making
the final jar as well.
Each have their pros and cons. Contrary to approach #b, which is an OSGi-first
approach, approach #a is where OSGi metadata generation is an additional step
in the build process. User sets up the their project following maven
conventions as per their packaging type and then they additionally configure
bundle plugin to help them generate a valid OSGi bundle. It is but natural that
many enterprise Java developers who are used to developing wars, ejb jars, etc.
prefer approach #a.
With all the recent fixes to maven-bundle-plugin, things have improved quite a
lot. Approach #a is an optimal way to generate proper OSGi bundle except when
there are dependencies embedded in the final jar. e.g., user may like to embed
some jars in their WEB-INF/lib of the WAB. In such a case, maven archiver knows
what all jars to be embedded; after all it is making the final war file. Yet,
one has to repeat some of this in Embed-Dependency instruction of bundle plugin
in order for bundle plugin to generate proper Bundle-ClassPath and
Import-Package header. If Embed-Dependency has extra jars, then unnecessary
Import-Package and Bundle-ClassPath will appear in the OSGi metadata. If
Embed-Dependency has less jars, then the reverse will happen. I agree to the
following comment made by Stuart in FELIX-1571:
"I think the proper solution may be to create a new feature that lets you
update the manifest in the generated project artifact. That way you have the
WAR artifact available, so bnd can produce the right manifest (and verify it) -
although one outstanding issue is this might affect signing... "
I don't know if there is someway to intercept maven-archiver processing, then
bundle plugin could generate the manifest as the penultimate step in the
packaging process. Anyway, I am sure with all the maven experts around, someone
will suggest a way to do this.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
