Re: Possible way to use feature plugin packagings in the karaf build

[David Jencks <da...@yahoo.com>]

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 <da...@yahoo.com> 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
>