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
