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]
