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
