You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by David Jencks <da...@yahoo.com> on 2011/02/06 03:25:51 UTC
Possible way to use feature plugin packagings in the karaf build
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?
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
Re: Possible way to use feature plugin packagings in the karaf build
Posted by 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
>
Re: Possible way to use feature plugin packagings in the karaf build
Posted by David Jencks <da...@yahoo.com>.
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
Re: Possible way to use feature plugin packagings in the karaf build
Posted by Andreas Pieber <an...@gmail.com>.
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
Re: Possible way to use feature plugin packagings in the karaf build
Posted by David Jencks <da...@yahoo.com>.
On Feb 7, 2011, at 12:29 AM, 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 ?
I think so. If I have a few minutes soon I'll try that.
> But won't the problem still happen in release:perform when building
> the non snapshot version ?
Well, I haven't tried with the release plugin yet but what I think will happen is:
release prepare will use the 2.1.99-SNAPSHOT (or 2.2 if available) features plugin to build karaf, in particular a 3.0 features-maven-plugin which will go in the local maven repo.
release perform will use the 3.0 features plugin just built from the local maven repo to build karaf.
thanks
david jencks
>
>>
>> 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
Re: Possible way to use feature plugin packagings in the karaf build
Posted by Guillaume Nodet <gn...@gmail.com>.
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