I'm not aware of any effort related to maven 3 yet. As for the war and ipojo protocols, i don't think it would work well. The features plugin try to generate a list of bundles using the mvn protocol only iirc. And if you use something else, it won't be able to understand and find the required dependencies.
I fear you may run into more problems trying to use the plugin than maintaining the feature manually. On Thu, May 6, 2010 at 14:38, Bengt Rodehav <[email protected]> wrote: > I also have another problem with the plugin. I don't seem to be able > to run it using maven 3 beta. I get the following error: > > [ERROR] Failed to execute goal > org.apache.felix.karaf.tooling:features-maven-plu > gin:1.4.0:add-features-to-repo (add-features-to-repo) on project assembly: > Error > populating repository: unknown protocol: null -> [Help 1] > > Note that I get this error even if I remove all references to "ipojo:" > and "war:". It seems to be a completely different problem. The plugin > works using maven 2.2.1 but we are in the process of migrating to > maven 3 and try to make sure that all our pom's work with the beta > version. Do you know if anyone have tried the plugin using maven 3? Is > anyone looking into maven 3 support? > > /Bengt > > > 2010/5/6 Bengt Rodehav <[email protected]>: > > Guillaume, > > > > I think I probably misunderstood how to use the plugin. I wasn't aware > > that all dependencies must be added to the maven project. I was hoping > > that they could be resolved anyway since they are listed in the > > features file. When I add all the dependencies, they will be installed > > in my local repo and is accessible to the plugin. > > > > I've now got almost everything to work expect for the url's that are > > not "mvn:". I also use "ipojo:" and "war:" in my features file, e g: > > > > > > <bundle>war:mvn:se.digia.connect/gui-war/${project.version}/war?Webapp-Context=connect_gui</bundle> > > > > <bundle>ipojo:mvn:se.digia.connect/test-route-template/${project.version}</bundle> > > > > How can I get the features-maven-plugin to work with those? At this > > point I'm not actually installing anything in Karaf, which means that > > the protocol in front of "mvn:" ("ipojo:" and "war:") should actually > > be skipped. Is there a workaround for this? > > > > /Bengt > > > > > > 2010/5/5 Guillaume Nodet <[email protected]>: > >> Not sure to fully understand, but if those are dependencies of your > maven > >> project, they should be in your local repo, shouldn't they ? > >> > >> On Wed, May 5, 2010 at 23:02, Bengt Rodehav <[email protected]> wrote: > >> > >>> It seems like the features-maven-plugin is exactly what I'm looking > >>> for. However I do run into one problem. I'm using a repository manager > >>> (Nexus) but the features-maven-plugin seems to only look in the locak > >>> repository (which doesn't contain everything). I get the following > >>> error message: > >>> > >>> [INFO] [features:add-features-to-repo {execution: > add-features-to-repo}] > >>> Base repo: file://C:/dev/Maven/repository > >>> Copy: commons-pool/commons-pool/1.5.4/commons-pool-1.5.4.jar > >>> Copy: > >>> org/apache/felix/karaf/shell/org.apache.felix.karaf.shell.ssh/1.4.0/o > >>> rg.apache.felix.karaf.shell.ssh-1.4.0.jar > >>> Copy: > >>> org/springframework/osgi/spring-osgi-annotation/1.2.0/spring-osgi-ann > >>> otation-1.2.0.jar > >>> Copy: org/ops4j/pax/web/pax-web-api/0.7.2/pax-web-api-0.7.2.jar > >>> [INFO] > >>> > ------------------------------------------------------------------------ > >>> [ERROR] BUILD ERROR > >>> [INFO] > >>> > ------------------------------------------------------------------------ > >>> [INFO] Error populating repository > >>> > >>> Can I configure the plugin to use Nexus instead? It's a bit strange > >>> because first everything is being downloaded to Nexus (due to the > >>> dependencies I've added), but then when the plugin kicks in and the > >>> repository is about to be created, only the local repo is being > >>> searched. > >>> > >>> Any ideas? > >>> > >>> /Bengt > >>> > >>> > >>> 2010/5/5 Bengt Rodehav <[email protected]>: > >>> > Thanks a lot Guillaume - I will definitely take a look at the plugin > >>> > you mentioned. > >>> > > >>> > /Bengt > >>> > > >>> > 2010/5/5 Guillaume Nodet <[email protected]>: > >>> >> We actually have a maven plugin that helps in doing that. > >>> >> Take a look at how we package ServiceMix NMR or the full ServiceMix > >>> >> distribution. > >>> >> It's based on Karaf, but includes some changes and additional > bundles > >>> >> configured > >>> >> using features. It sounds exactly like what you want. > >>> >> > http://svn.apache.org/repos/asf/servicemix/smx4/nmr/trunk/assembly/ > >>> >> > >>> >> The plugin could be enhanced to make this task easier though, but > it's > >>> still > >>> >> a good > >>> >> starting point. The final packaging and other changes are done > using > >>> the > >>> >> maven > >>> >> assembly plugin. Any help / suggestion / patch would be welcomed ! > >>> >> > >>> >> As for maven, two things: > >>> >> * first, if a bundle can be located in the system folder, it won't > try > >>> to > >>> >> find it in any > >>> >> other maven repository, even for a snapshot > >>> >> * second, the list of repositories where the maven url handler can > >>> >> download the > >>> >> artifacts from can be configured in etc/org.ops4j.pax.url.mvn.cfg > >>> >> I agree i would not let artifacts be downloaded from the internet > >>> either. A > >>> >> nice configuration > >>> >> would be to point to a nexus repository manager and the work there. > >>> >> > >>> >> > >>> >> On Wed, May 5, 2010 at 11:18, Bengt Rodehav <[email protected]> > wrote: > >>> >> > >>> >>> I'm building an integration platform using Camel deployed in Karaf. > >>> >>> The platform will be used for different kinds of applications > (mainly > >>> >>> integration oriented of course). I'm not entirely sure how I best > >>> >>> construct an installation program for these applications. Basically > I > >>> >>> need to: > >>> >>> > >>> >>> a) Install Karaf. This is as easy as unpacking a zip file - very > >>> >>> convenient. > >>> >>> b) Configure Karaf. I will change some of the configuration files > and > >>> >>> add some. This is not hard. > >>> >>> c) Install the bundles needed for my application. This is where I > need > >>> >>> some advice. > >>> >>> > >>> >>> My bundles are installed in two ways: via startup.properties and > via > >>> >>> features defined in org.apache.felix.karaf.features.cfg. The > bundles > >>> >>> in startup.properties refer to its location in the folder "system" > >>> >>> under the Karaf installation. I will probably define an additional > >>> >>> folder where I will put bundles that I add to startup.properties. > This > >>> >>> is to clearly distinguish between the standard Karaf installation > >>> >>> (which I want to be able to upgrade easily) and my application > >>> >>> specific bundles. Don't know how I do this but I imagine it is > >>> >>> configurable somehow. > >>> >>> > >>> >>> However, most of my required bundles are installed as Karaf > features > >>> >>> via maven (the url's begin with mvn:). In a development environment > >>> >>> this is very convenient. In a production environment I do not want > my > >>> >>> application to go out on the Internet looking for bundles. I want > it > >>> >>> to be totally self sustained. In other words, I want my > installation > >>> >>> to contain (in a subfolder to the Karaf installation) all the > needed > >>> >>> jars/bundles. My problem is how do I generate a folder containing > all > >>> >>> my required bundles from a list of features (with the "mvn:" url)? > >>> >>> Ideally I would list the features I want and then automatically > >>> >>> generate a folder containing all the referred bundles. I would then > >>> >>> include this folder in my installation. > >>> >>> > >>> >>> Has anyone solved this problem (going from development to > production > >>> >>> using Karaf)? What is best practice? > >>> >>> > >>> >>> /Bengt > >>> >>> > >>> >>> > --------------------------------------------------------------------- > >>> >>> To unsubscribe, e-mail: [email protected] > >>> >>> For additional commands, e-mail: [email protected] > >>> >>> > >>> >>> > >>> >> > >>> >> > >>> >> -- > >>> >> Cheers, > >>> >> Guillaume Nodet > >>> >> ------------------------ > >>> >> Blog: http://gnodet.blogspot.com/ > >>> >> ------------------------ > >>> >> Open Source SOA > >>> >> http://fusesource.com > >>> >> > >>> > > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >>> > >> > >> > >> -- > >> Cheers, > >> Guillaume Nodet > >> ------------------------ > >> Blog: http://gnodet.blogspot.com/ > >> ------------------------ > >> Open Source SOA > >> http://fusesource.com > >> > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
