Mhm... I'm still not sure if we want to use the karaf-maven-plugin ourself. Maybe we could start separating "karaf-core" and "karaf-features"? This way we could simply use the assembly plugin to build the core and only have to use the karaf-maven-plugin in the feature project completely free us of this problem?
kind regards, andreas On Mon, Feb 07, 2011 at 09:29:36AM +0100, Guillaume Nodet wrote: > On Sun, Feb 6, 2011 at 03:25, David Jencks <[email protected]> wrote: > > I might have come up with a way to use the feature plugin packagings in the > > karaf build without profiles as long as we don't use backwards incompatible > > changes in our builds. The main problem I know about is using the release > > plugin to do a release because the new version of the features-maven-plugin > > isn't available in a maven repo yet. > > > > The idea is to define the version of the features-maven-plugin in a maven > > property and override it on the build command line to a previously released > > version. > > > > I've tried this locally with the 2.1.99-SNAPSHOT branch and > > 2.99.99-SNAPSHOT trunk. > > > > First I built the 2.1.99-SNAPSHOT tree to get this version of the plugin in > > my local repo. > > > > Then I cleaned out any mention of the 2.99.99-SNAPSHOT plugin from my repo > > and build trunk with > > > > mvn clean install -DfeaturesPluginVersion=2.1.99-SNAPSHOT > > > > aside from some test failures and problems with a missing war deployer and > > manual artifacts, this worked fine, using the old 2.1.99-SNAPSHOT plugin. > > It also built the 2.99.99-SNAPSHOT plugin. > > > > Then I built trunk > > mvn clean install > > > > which worked just as well, using the new plugin. > > > > So, I think we can leverage this idea in the release plugin, since it > > builds twice with the new version: for release:prepare we use something on > > the command line to get the plugin version into the forked maven command > > line, and for release perform we leave this out. > > > > I think to actually find out if this will work I'll need to do a > > release:prepare on trunk, creating an svn tag which I can then remove > > again. Does this seem worth experimenting with further or is it too > > complicated or does someone know that it won't work? > > Couldn't we create two branches for experimenting so that trunk and > the maintenance branches won't be affected at all ? > But won't the problem still happen in release:perform when building > the non snapshot version ? > > > > > I think this actually ought to work with version ranges on the plugin but > > AFAICT this is going to show up so many maven bugs as to be unworkable. > > > > thanks > > david jencks > > > > > > > > -- > Cheers, > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com
pgphWlAI7rck8.pgp
Description: PGP signature
