I think that Guillaume suggested some time ago that perhaps we could use the feature-maven-plugin mojos in a pom packaging project so as not to run into these problems. I tried this out with the karaf-framework kar and it seems to work fine and give exactly the same output. I'm going to put my "framework" kar back in the build this way. I hope to have time soon to check that we can do the same with assembling karafs using feature-maven-plugin.
thanks david jencks On Feb 7, 2011, at 1:00 AM, David Jencks wrote: > If you are ok with having 2 projects, then you can just put the core assembly > in the 2nd project and use the feature plugin to build it. > > Based on my experience in geronimo I really like building all the servers the > same way with an assembly tool that fits. Using this tool in the main > artifact is also a check that it works all the time. I would expect that > otherwise we'll periodically break it and not notice for weeks. > > thanks > david jencks > > On Feb 7, 2011, at 12:40 AM, Andreas Pieber wrote: > >> 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 >
