[jira] [Updated] (FELIX-3018) Allow updation of an artifact's manifest at the final stage

["Stuart McCulloch (JIRA)" <ji...@apache.org>]

     [ 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