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 ? > > 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. > /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
