You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by Stuart McCulloch <mc...@gmail.com> on 2009/04/18 03:40:40 UTC
Next release of the Felix parent pom [1.1.0]
Hi,
I'd like to stage a new release of our parent pom (ie. pom/pom.xml) - this
will exercise the new release process.
Are there any objections to starting this? Does anyone have any changes they
would like to make to this pom?
Note that this isn't a vote on the actual release - I will start that once
I've staged it using Nexus.
Also please hold off from any new releases until I've tried out the new
process and documented it on the wiki :)
--
Cheers, Stuart
Re: Next release of the Felix parent pom [1.1.0]
Posted by Carsten Ziegeler <cz...@apache.org>.
Stuart McCulloch schrieb:
> 2009/4/18 Felix Meschberger <fm...@gmail.com>
>
>> Hi,
>>
>> Clement Escoffier schrieb:
>>> Hi,
>>> On 18.04.2009, at 11:41, Felix Meschberger wrote:
>>>
>>>> Hi Stuart,
>>>>
>>>> Stuart McCulloch schrieb:
>>>>> Hi,
>>>>>
>>>>> I'd like to stage a new release of our parent pom (ie. pom/pom.xml) -
>>>>> this
>>>>> will exercise the new release process.
>>>>> Are there any objections to starting this? Does anyone have any
>>>>> changes they
>>>>> would like to make to this pom?
>>>>>
>>>>> Note that this isn't a vote on the actual release - I will start that
>>>>> once
>>>>> I've staged it using Nexus.
>>>>>
>>>>> Also please hold off from any new releases until I've tried out the new
>>>>> process and documented it on the wiki :)
>>>> Can we split the parent pom (definitions pertaining to all Felix
>>>> projects) and reactor (<modules> section) functionalities into into two
>>>> files by that matter ?
>>>>
>>>> We could for example create a reactor project at trunk, which stays at
>>>> SNAPSHOT version for ever and which we can update as we see fit to
>>>> accomodate new child projects.
>>>>
>>>> The actual parent pom would remain where it was and would be updated and
>>>> released for release new general setup such as the deployment
>>>> configuration.
>>>>
>>>> In addition it is IMO also a matter of separation of concerns (reactor
>>>> vs. general setup). We have done this in the Sling and Jackrabbit
>>>> projects with much success (IMHO).
>>> I agree having two files:
>>> - one with the reactor configuration and
>>> - one with the release / project configuration
>>> sounds good.
>>>
>>> Projects should inherit of the release / project configuration pom file.
>>>
>>> However, aren't we already in this mode ? Recently, I saw a pom file in
>>> the Felix root (the reactor one ?) and one in the pom folder.
>> I was confused by this file, too.
>>
>> But the actual reactor is in the pom/pom.xml file.
>>
>
> That's not quite right - Carsten created a top-level pom with a copy of the
> reactor and left
> the old modules definition in the parent pom.
Argh, that was an oversight then :( Sorry, I forgot to commit my local
copy of the parent pom :(
Carsten
--
Carsten Ziegeler
cziegeler@apache.org
Re: Next release of the Felix parent pom [1.1.0]
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Stuart McCulloch schrieb:
> 2009/4/18 Felix Meschberger <fm...@gmail.com>
>
>> Hi,
>>
>> Clement Escoffier schrieb:
>>> Hi,
>>> On 18.04.2009, at 11:41, Felix Meschberger wrote:
>>>
>>>> Hi Stuart,
>>>>
>>>> Stuart McCulloch schrieb:
>>>>> Hi,
>>>>>
>>>>> I'd like to stage a new release of our parent pom (ie. pom/pom.xml) -
>>>>> this
>>>>> will exercise the new release process.
>>>>> Are there any objections to starting this? Does anyone have any
>>>>> changes they
>>>>> would like to make to this pom?
>>>>>
>>>>> Note that this isn't a vote on the actual release - I will start that
>>>>> once
>>>>> I've staged it using Nexus.
>>>>>
>>>>> Also please hold off from any new releases until I've tried out the new
>>>>> process and documented it on the wiki :)
>>>> Can we split the parent pom (definitions pertaining to all Felix
>>>> projects) and reactor (<modules> section) functionalities into into two
>>>> files by that matter ?
>>>>
>>>> We could for example create a reactor project at trunk, which stays at
>>>> SNAPSHOT version for ever and which we can update as we see fit to
>>>> accomodate new child projects.
>>>>
>>>> The actual parent pom would remain where it was and would be updated and
>>>> released for release new general setup such as the deployment
>>>> configuration.
>>>>
>>>> In addition it is IMO also a matter of separation of concerns (reactor
>>>> vs. general setup). We have done this in the Sling and Jackrabbit
>>>> projects with much success (IMHO).
>>> I agree having two files:
>>> - one with the reactor configuration and
>>> - one with the release / project configuration
>>> sounds good.
>>>
>>> Projects should inherit of the release / project configuration pom file.
>>>
>>> However, aren't we already in this mode ? Recently, I saw a pom file in
>>> the Felix root (the reactor one ?) and one in the pom folder.
>> I was confused by this file, too.
>>
>> But the actual reactor is in the pom/pom.xml file.
>>
>
> That's not quite right - Carsten created a top-level pom with a copy of the
> reactor and left
Missed that one. Thanks for the update.
> the old modules definition in the parent pom. Since then new modules have
> been added
> to the top-level pom (hence the email about the build not working from the
> "pom" dir)
>
> I've removed the modules definition from the parent pom, because it's not
> needed anymore
> and just causes confusion (like this;) ... from now on modules should be
> added to the pom
> at the top of the project tree.
>
> So the top-level pom now has the reactor, and the parent pom has the global
> settings
Great !
Regards
Felix
>
>>> Another idea would to use -Pprofile name instead of -Dpackaging=xxx. For
>>> example we can define a "default", a test profile, and an example
>> Sounds reasonable.
>>
>> Regards
>> Felix
>>
>>> profile... The -Dpackaging=xxx was introduced to turn around a bug in
>>> Maven avoiding having different packaging types in a project. However,
>>> this issue is now fixed. So, maybe we can just remove this separation.
>>>
>>> Regards,
>>>
>>> Clement
>>>
>>>
>>>>
>>>> Regards
>>>> Felix
>>>>
>>>
>
>
>
Re: Next release of the Felix parent pom [1.1.0]
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/4/18 Felix Meschberger <fm...@gmail.com>
> Hi,
>
> Clement Escoffier schrieb:
> > Hi,
> > On 18.04.2009, at 11:41, Felix Meschberger wrote:
> >
> >> Hi Stuart,
> >>
> >> Stuart McCulloch schrieb:
> >>> Hi,
> >>>
> >>> I'd like to stage a new release of our parent pom (ie. pom/pom.xml) -
> >>> this
> >>> will exercise the new release process.
> >>> Are there any objections to starting this? Does anyone have any
> >>> changes they
> >>> would like to make to this pom?
> >>>
> >>> Note that this isn't a vote on the actual release - I will start that
> >>> once
> >>> I've staged it using Nexus.
> >>>
> >>> Also please hold off from any new releases until I've tried out the new
> >>> process and documented it on the wiki :)
> >>
> >> Can we split the parent pom (definitions pertaining to all Felix
> >> projects) and reactor (<modules> section) functionalities into into two
> >> files by that matter ?
> >>
> >> We could for example create a reactor project at trunk, which stays at
> >> SNAPSHOT version for ever and which we can update as we see fit to
> >> accomodate new child projects.
> >>
> >> The actual parent pom would remain where it was and would be updated and
> >> released for release new general setup such as the deployment
> >> configuration.
> >>
> >> In addition it is IMO also a matter of separation of concerns (reactor
> >> vs. general setup). We have done this in the Sling and Jackrabbit
> >> projects with much success (IMHO).
> >
> > I agree having two files:
> > - one with the reactor configuration and
> > - one with the release / project configuration
> > sounds good.
> >
> > Projects should inherit of the release / project configuration pom file.
> >
> > However, aren't we already in this mode ? Recently, I saw a pom file in
> > the Felix root (the reactor one ?) and one in the pom folder.
>
> I was confused by this file, too.
>
> But the actual reactor is in the pom/pom.xml file.
>
That's not quite right - Carsten created a top-level pom with a copy of the
reactor and left
the old modules definition in the parent pom. Since then new modules have
been added
to the top-level pom (hence the email about the build not working from the
"pom" dir)
I've removed the modules definition from the parent pom, because it's not
needed anymore
and just causes confusion (like this;) ... from now on modules should be
added to the pom
at the top of the project tree.
So the top-level pom now has the reactor, and the parent pom has the global
settings
>
> > Another idea would to use -Pprofile name instead of -Dpackaging=xxx. For
> > example we can define a "default", a test profile, and an example
>
> Sounds reasonable.
>
> Regards
> Felix
>
> > profile... The -Dpackaging=xxx was introduced to turn around a bug in
> > Maven avoiding having different packaging types in a project. However,
> > this issue is now fixed. So, maybe we can just remove this separation.
> >
> > Regards,
> >
> > Clement
> >
> >
> >>
> >>
> >> Regards
> >> Felix
> >>
> >
> >
>
--
Cheers, Stuart
Re: Next release of the Felix parent pom [1.1.0]
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Clement Escoffier schrieb:
> Hi,
> On 18.04.2009, at 11:41, Felix Meschberger wrote:
>
>> Hi Stuart,
>>
>> Stuart McCulloch schrieb:
>>> Hi,
>>>
>>> I'd like to stage a new release of our parent pom (ie. pom/pom.xml) -
>>> this
>>> will exercise the new release process.
>>> Are there any objections to starting this? Does anyone have any
>>> changes they
>>> would like to make to this pom?
>>>
>>> Note that this isn't a vote on the actual release - I will start that
>>> once
>>> I've staged it using Nexus.
>>>
>>> Also please hold off from any new releases until I've tried out the new
>>> process and documented it on the wiki :)
>>
>> Can we split the parent pom (definitions pertaining to all Felix
>> projects) and reactor (<modules> section) functionalities into into two
>> files by that matter ?
>>
>> We could for example create a reactor project at trunk, which stays at
>> SNAPSHOT version for ever and which we can update as we see fit to
>> accomodate new child projects.
>>
>> The actual parent pom would remain where it was and would be updated and
>> released for release new general setup such as the deployment
>> configuration.
>>
>> In addition it is IMO also a matter of separation of concerns (reactor
>> vs. general setup). We have done this in the Sling and Jackrabbit
>> projects with much success (IMHO).
>
> I agree having two files:
> - one with the reactor configuration and
> - one with the release / project configuration
> sounds good.
>
> Projects should inherit of the release / project configuration pom file.
>
> However, aren't we already in this mode ? Recently, I saw a pom file in
> the Felix root (the reactor one ?) and one in the pom folder.
I was confused by this file, too.
But the actual reactor is in the pom/pom.xml file.
>
> Another idea would to use -Pprofile name instead of -Dpackaging=xxx. For
> example we can define a "default", a test profile, and an example
Sounds reasonable.
Regards
Felix
> profile... The -Dpackaging=xxx was introduced to turn around a bug in
> Maven avoiding having different packaging types in a project. However,
> this issue is now fixed. So, maybe we can just remove this separation.
>
> Regards,
>
> Clement
>
>
>>
>>
>> Regards
>> Felix
>>
>
>
Re: Next release of the Felix parent pom [1.1.0]
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/4/18 Clement Escoffier <cl...@gmail.com>
> Hi,
>
> On 18.04.2009, at 11:41, Felix Meschberger wrote:
>
> Hi Stuart,
>>
>> Stuart McCulloch schrieb:
>>
>>> Hi,
>>>
>>> I'd like to stage a new release of our parent pom (ie. pom/pom.xml) -
>>> this
>>> will exercise the new release process.
>>> Are there any objections to starting this? Does anyone have any changes
>>> they
>>> would like to make to this pom?
>>>
>>> Note that this isn't a vote on the actual release - I will start that
>>> once
>>> I've staged it using Nexus.
>>>
>>> Also please hold off from any new releases until I've tried out the new
>>> process and documented it on the wiki :)
>>>
>>
>> Can we split the parent pom (definitions pertaining to all Felix
>> projects) and reactor (<modules> section) functionalities into into two
>> files by that matter ?
>>
>> We could for example create a reactor project at trunk, which stays at
>> SNAPSHOT version for ever and which we can update as we see fit to
>> accomodate new child projects.
>>
>> The actual parent pom would remain where it was and would be updated and
>> released for release new general setup such as the deployment
>> configuration.
>>
>> In addition it is IMO also a matter of separation of concerns (reactor
>> vs. general setup). We have done this in the Sling and Jackrabbit
>> projects with much success (IMHO).
>>
>
> I agree having two files:
> - one with the reactor configuration and
> - one with the release / project configuration
> sounds good.
>
> Projects should inherit of the release / project configuration pom file.
>
> However, aren't we already in this mode ? Recently, I saw a pom file in the
> Felix root (the reactor one ?) and one in the pom folder.
>
yep, that's where we're headed ;)
> Another idea would to use -Pprofile name instead of -Dpackaging=xxx. For
> example we can define a "default", a test profile, and an example profile...
> The -Dpackaging=xxx was introduced to turn around a bug in Maven avoiding
> having different packaging types in a project. However, this issue is now
> fixed. So, maybe we can just remove this separation.
>
possibly, though we may have people using back-level versions of Maven - but
definitely something to look into...
> Regards,
>
> Clement
>
>
>
>>
>> Regards
>> Felix
>>
>>
>
--
Cheers, Stuart
Re: Next release of the Felix parent pom [1.1.0]
Posted by Clement Escoffier <cl...@gmail.com>.
Hi,
On 18.04.2009, at 11:41, Felix Meschberger wrote:
> Hi Stuart,
>
> Stuart McCulloch schrieb:
>> Hi,
>>
>> I'd like to stage a new release of our parent pom (ie. pom/pom.xml)
>> - this
>> will exercise the new release process.
>> Are there any objections to starting this? Does anyone have any
>> changes they
>> would like to make to this pom?
>>
>> Note that this isn't a vote on the actual release - I will start
>> that once
>> I've staged it using Nexus.
>>
>> Also please hold off from any new releases until I've tried out the
>> new
>> process and documented it on the wiki :)
>
> Can we split the parent pom (definitions pertaining to all Felix
> projects) and reactor (<modules> section) functionalities into into
> two
> files by that matter ?
>
> We could for example create a reactor project at trunk, which stays at
> SNAPSHOT version for ever and which we can update as we see fit to
> accomodate new child projects.
>
> The actual parent pom would remain where it was and would be updated
> and
> released for release new general setup such as the deployment
> configuration.
>
> In addition it is IMO also a matter of separation of concerns (reactor
> vs. general setup). We have done this in the Sling and Jackrabbit
> projects with much success (IMHO).
I agree having two files:
- one with the reactor configuration and
- one with the release / project configuration
sounds good.
Projects should inherit of the release / project configuration pom file.
However, aren't we already in this mode ? Recently, I saw a pom file
in the Felix root (the reactor one ?) and one in the pom folder.
Another idea would to use -Pprofile name instead of -Dpackaging=xxx.
For example we can define a "default", a test profile, and an example
profile... The -Dpackaging=xxx was introduced to turn around a bug in
Maven avoiding having different packaging types in a project. However,
this issue is now fixed. So, maybe we can just remove this separation.
Regards,
Clement
>
>
> Regards
> Felix
>
Re: Next release of the Felix parent pom [1.1.0]
Posted by Stuart McCulloch <mc...@gmail.com>.
2009/4/18 Felix Meschberger <fm...@gmail.com>
> Hi Stuart,
>
> Stuart McCulloch schrieb:
> > Hi,
> >
> > I'd like to stage a new release of our parent pom (ie. pom/pom.xml) -
> this
> > will exercise the new release process.
> > Are there any objections to starting this? Does anyone have any changes
> they
> > would like to make to this pom?
> >
> > Note that this isn't a vote on the actual release - I will start that
> once
> > I've staged it using Nexus.
> >
> > Also please hold off from any new releases until I've tried out the new
> > process and documented it on the wiki :)
>
> Can we split the parent pom (definitions pertaining to all Felix
> projects) and reactor (<modules> section) functionalities into into two
> files by that matter ?
>
> We could for example create a reactor project at trunk, which stays at
> SNAPSHOT version for ever and which we can update as we see fit to
> accomodate new child projects.
>
this is already in progress - Carsten added a top-level pom with the reactor
> The actual parent pom would remain where it was and would be updated and
> released for release new general setup such as the deployment
> configuration.
>
that's the plan :)
> In addition it is IMO also a matter of separation of concerns (reactor
> vs. general setup). We have done this in the Sling and Jackrabbit
> projects with much success (IMHO).
>
> Regards
> Felix
>
--
Cheers, Stuart
Re: Next release of the Felix parent pom [1.1.0]
Posted by Felix Meschberger <fm...@gmail.com>.
Hi Stuart,
Stuart McCulloch schrieb:
> Hi,
>
> I'd like to stage a new release of our parent pom (ie. pom/pom.xml) - this
> will exercise the new release process.
> Are there any objections to starting this? Does anyone have any changes they
> would like to make to this pom?
>
> Note that this isn't a vote on the actual release - I will start that once
> I've staged it using Nexus.
>
> Also please hold off from any new releases until I've tried out the new
> process and documented it on the wiki :)
Can we split the parent pom (definitions pertaining to all Felix
projects) and reactor (<modules> section) functionalities into into two
files by that matter ?
We could for example create a reactor project at trunk, which stays at
SNAPSHOT version for ever and which we can update as we see fit to
accomodate new child projects.
The actual parent pom would remain where it was and would be updated and
released for release new general setup such as the deployment configuration.
In addition it is IMO also a matter of separation of concerns (reactor
vs. general setup). We have done this in the Sling and Jackrabbit
projects with much success (IMHO).
Regards
Felix