felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sahoo (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (FELIX-3018) Allow updation of an artifact's manifest at the final stage
Date Fri, 05 Aug 2011 09:57:28 GMT

    [ https://issues.apache.org/jira/browse/FELIX-3018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079880#comment-13079880
] 

Sahoo commented on FELIX-3018:
------------------------------

If there is no way to intercept maven archiver, then can we have another goal in maven-bundle-plugin
called something like wrap-wab which will be active for war packaging type and will turn the
project artifact to a wab? It will basically overwrite the war generated war to a wab with
same name. One can then attach this goal to package phase and there will no additional Bundle-ClassPath
configuration needed, as it can discover the same looking at the war.

> 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

        

Mime
View raw message