Done. https://issues.apache.org/jira/browse/FELIX-2329
/Bengt 2010/5/6 Guillaume Nodet <[email protected]>: > Attachements are usually stripped on the mailing list. > Would you mind raising a JIRA issue and attaching your patch to it ? > > On Thu, May 6, 2010 at 22:44, Bengt Rodehav <[email protected]> wrote: > >> Guillaume, >> >> Attached to this mail is a modified version of >> AddFeaturesToRepoMojo.java. I added two configuration parameters: >> >> - skipNonMavenProtocols: Setting this to true (false is default) >> causes the plugin to look for the first occurence of "mvn:" and start >> passing the url from there. This enables url's like >> >> "<bundle>ipojo:mvn:se.digia.connect/test-route-template/${project.version}</bundle>". >> >> - skipUrlParameters: Setting this to true (false is default) causes >> the plugin to truncate the url if a "#" or a "?" is encountered. This >> enables url's like: >> >> "<bundle>war:mvn:se.digia.connect/gui-war/${project.version}/war?Webapp-Context=connect_gui</bundle>" >> >> I haven't contributed to Apache before so you might want to check the >> code extra carefully. Note that I haven't modified >> ValidateFeaturesMojo.java. I understand that it implements the >> validate-features goal. Does it need to be changed too? I haven't used >> it so I wouldn't know. >> >> Anyway, the attached version solves the problems I've had so far. >> >> /Bengt >> >> >> 2010/5/6 Bengt Rodehav <[email protected]>: >> > I'll take a look at it... >> > >> > 2010/5/6 Guillaume Nodet <[email protected]>: >> >> Mmh, I think I misunderstood what you were trying to achieve. >> >> It's because the plugin can be used to actually generate the feature >> >> descriptor. >> >> If you have an existing feature repository, the plugin can be used to >> put >> >> all the jars >> >> in the system folder. And if this fail for other kind of url handlers, >> it >> >> should just do its best and not throw an error. >> >> Wanna try to modify the plugin to better support your ipojo and war url >> >> handlers ? >> >> >> >> On Thu, May 6, 2010 at 16:28, Bengt Rodehav <[email protected]> wrote: >> >> >> >>> Guillaume, >> >>> >> >>> Think I found the thread you were mentioning. Now I need to learn OBR >> >>> as well :-) >> >>> >> >>> Will using OBR via Karaf features solve the problem I'm trying to >> >>> solve? What I want to achieve is to create a local repository (under >> >>> my Karaf installation) that includes everything needed without having >> >>> to search for it in an external maven repository. I want a self >> >>> sustained application. Will OBR solve this? >> >>> >> >>> /Bengt >> >>> >> >>> 2010/5/6 Bengt Rodehav <[email protected]>: >> >>> > 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] >> >>> >> >>> >> >> >> >> >> >> -- >> >> 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]
