felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Guillaume Nodet (JIRA)" <j...@apache.org>
Subject [jira] Commented: (FELIX-1080) Enhance features maven plugin to support deployment / undeployment of features, html generation and create a few archetypes
Date Tue, 28 Apr 2009 16:23:30 GMT

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

Guillaume Nodet commented on FELIX-1080:

Edell Nolan:

I have been working on creating an archetype to generate a feature descriptor automatically
if you add in dependencies into a pom.xml file - our maven features plugin does this already
and I have the archetype working. But I have a question around having multiple pom.xml files
in that you have a root pom and serveral modules. if you then attempt to run this from the
root - I get the impression you are looking for a features.xml file that would have covered
all the module poms.xml files. so that it will add the features for all dependencies in all
the sub modules

Is this the case ? or should it be that you just generate the features.xml for each module
individually ?

Charles Mouillard:

Personally, I prefer to have one feature file generated when we have a parent pom with several
slave pom (= modules). 

Guillaume Nodet:

I'm not sure that this is a good idea to generate the features file from the parent pom in
case you have modules that are not really part of the feature, like an assembly of something
like that.

Edell Nolan:

I was thinking about this a little more and I think it should just be based on one feature.xml
file per pom.xml with its dependencies.
You can always have one directory that will list all your dependencies and use this to create
your features.xml file.

I will get this in today hopefully.

Charles Mouillard:

Most of the time, when you work on a OSGI project, you will create in eclipse several eclipse
projects, one by bundle. So, it makes sense to create a parent pom pointing to the different
modules / bundles and to have one global features file.

Here is an example of what I do manually to deploy all my bundles :

<feature name="reportincident" version="1.0">

reportincident.domain = maven project = bundle = eclipse project

Edell Nolan:

Ok The way this currently works is that you would have one pom that would list dependencies

camel-core, camel-spring etc so this will generate your features.xml file - Also if you wish
- it will indicate what other bundles it requires for classes that you may have not depended
on and you can supply this list in a properties file so it will include dependent bundles
for you as well.

I will do up an example: that we did for our distribution of camel in servicemix. 

Edell Nolan:

Attaching a patch - you will need the latest of the features maven plugin or change the version
in the generated pom
It depends on


Example here : if you run

Step1 :
C:\edell-features>mvn archetype:create -DarchetypeGroupId=org.apache.servicemix.tooling
-DarchetypeArtifactId=servicemix-features-descriptor -DgroupId=org.apache.servicemix.edell
-DartifactId=org.apache.servicemix.testCamel.features -DarchetypeVersion=2008.01-SNAPSHOT

This will generate the following directory structure

-> pom.xml
-> src/main/resources/bundle.properties

If you run mvn install => this will result in a features.xml file with nothing in it.

<?xml version="1.0" encoding="UTF-8"?>

Step 2:
Your next step is to add your dependencies into the pom.xml file
so if I added


This will result in target/classes/feature.xml file

<?xml version="1.0" encoding="UTF-8"?>
<feature name='camel-core'>

But it will also hint in the output about dependant bundles

[WARNING] Unable to find suitable bundle for dependency javax.activation (0.0.
0) (required by camel-core)
[WARNING] Unable to find suitable bundle for dependency javax.xml.bind (0.0.0)
(required by camel-core)
[WARNING] Unable to find suitable bundle for dependency javax.xml.bind.annotat
ion (0.0.0) (required by camel-core)

Step 3:

You can add the dependant bundles to your bundle.properties file

So you get a resulting feature.xml file

<?xml version="1.0" encoding="UTF-8"?>
<feature name='camel-core'>

Edell Nolan:

You need to apply the patch to the servicemix-archetypes project. 

Charles Mouillard:

Many thanks. I will try to have a look this afternoon or tomorrow. 

Edell Nolan:

I am going to create sub-tasks for each of the above archetypes etc 

Charles Mouillard:

Question : Do you filter the dependencies when generating the feature.xml to allow add the
dependencies with scope = runtime ? It makes no sense to put in the feature file dependency
only used for testing, by plugin and only compilation ?

Charles Mouillard:

Hi Edell,

How can I test on my PC the patch ? 

Edell Nolan:


You need to apply this patch to the latest of Servicemix archetypes => https://svn.apache.org/repos/asf/servicemix/archetypes/trunk

You may also need to do an update to the plugins as I fixed one/two bugs for NPE in the features

Then attempt to create an archetype like I have described above - this patch curently only
goes as far as generating your features.xml file.

For the uploading - which is really installing everything in the features.xml - I am currently
working on this part.

Does this help ?


Charles Mouillard:

I hope. I thought that the patch should be applied here : http://svn.apache.org/repos/asf/servicemix/maven-plugins/features-maven-plugin.
I will add it to where you propose and test.

Can you answer to my previous question : Do you filter dependencies .... ?

Edell Nolan:


No it doesn't appear to scope=runtime - I will look into this.


Charles Mouillard:


The level of the packaging of the pom.xml created is pom. Is it correct or should it be bundle
By the way, it should be interesting to add directly the maven-felix plugin in the pom because
the code generated will be deployed as a bundle in SMX 

Charles Mouillard:


It should be interesting that the plugin works also with pom where <module> are defined.

This could be very helpful because the feature file generated could be the sum of the features
file created for each pom sub-project. Therefore, we have only one file to use to deploy our
application containing different bundles (dao, domain, services, web, ...

Name of the project : ReportIncident (= parent pom)
module : dao
module : domain
module : service

For each module, we have a feature file.

When we launch mvn install (parent pom), the report incident feature file is generated and
contains :

<feature name='dao'/>
<feature name='domain'/>
<feature name='service'/>

<feature name='dao version='A.0-SNAPSHOT'>
<mvn: .....>



> Enhance features maven plugin to support deployment / undeployment of features, html
generation and create a few archetypes
> ---------------------------------------------------------------------------------------------------------------------------
>                 Key: FELIX-1080
>                 URL: https://issues.apache.org/jira/browse/FELIX-1080
>             Project: Felix
>          Issue Type: New Feature
>          Components: Karaf
>            Reporter: Guillaume Nodet
> Enhance the features maven plugin (http://svn.apache.org/repos/asf/servicemix/maven-plugins/features-maven-plugin)
to support :
> 1) Deployment / undeployment of features,
> 2) Generate html page about features : see http://fusesource.com/forums/message.jspa?messageID=2005#2005
for the suggestion
> 3) Creation a few archetypes:
>     * one for creating a custom smx kernel distribution + a set of
>       features (like what we do for our distributions).
>     * one for creating a feature descriptor automatically generated
>       using the maven plugin we already have + upload in the maven repo. Ideally, the
descriptor should be created from the user pom.xml profile file or (pom.xml files if the user
has created a parent pom.xml with modules)
>     * one for creating a manually written feature descriptor + upload in
>       the maven repo
> The two last archetypes should reference our maven plugin so that they
> could be easily installed / uninstalled to a running (or not) smx4
> kernel instance using maven.
> Remark : this ticket has been created following discussions exchanged in the forum of
SMX : http://www.nabble.com/forum/ViewPost.jtp?post=22285345&framed=y

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message