[
https://issues.apache.org/jira/browse/FELIX-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stuart McCulloch updated FELIX-3018:
------------------------------------
Fix Version/s: maven-bundle-plugin-patches-welcome
> 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
> Fix For: maven-bundle-plugin-patches-welcome
>
>
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
