You could package up all of your JARs and place them in an OBR that you install locally (on the same box as Felix Karaf). At that point you could use the obr.xml to start up your application. You'd have to figure out how to change the URIs though in the obr.xml - when you "mvn install" the obr.xml that gets generated references ~/.m2/repository rather than some other local directory.
-c On Thu, May 6, 2010 at 10:28 AM, 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] > >
