See comments below... 2010/5/6 Guillaume Nodet <[email protected]>: > On Thu, May 6, 2010 at 16:02, Bengt Rodehav <[email protected]> wrote: > >> Regarding the non" mvn:" protocols, I guess I'll either have to stop >> using them as part of features or somehow exclude them fromthe >> features-maven-plugin and handle them manually. It's a shame though... >> Wouldn't it be a reasonable enhancement to the plugin to be able to >> skip leading protocols as long as" mvn:" is present further down the >> url? >> > > Well, if we do the enhancement i talked about in another thread, which is to > let > OBR kick in and resolve any missing dependency, then the plugin would not > be really helpfull anymore, would it ? > > >>> >>> I've totally missed this thread. Will check it out. Do you mean that the >>> alternate solution (OBR...) you mention will render the >>> features-maven-plugin unnecessary? >>> >> >> Regarding maven 3, I think it can only be a matter of timing. Sooner >> or later it should/must be supported. I think maven 3 compatibility >> should also be added to the "todo list" (JIRA I guess). >> >> > Agreed, but if we can't support both at the same time, i'd rather wait until > 3.0 is released. > >>> I totally understand that. However, I haven't seen that situation before >>> since maven 3 is designed to be totally backwards compatible. Most of the >>> time the problems arise when the plugins use some unsupported/undocumented >>> feature. >>> >> /Bengt >> >> >> 2010/5/6 Guillaume Nodet <[email protected]>: >> > 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 >> > >> >> --------------------------------------------------------------------- >> 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]
