commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: [all][maven 2 configuration]
Date Wed, 30 Aug 2006 04:17:07 GMT
It's either an error in the docs, or my memory is failing me :)

On 30/08/2006, at 1:40 PM, Phil Steitz wrote:

> On 8/29/06, Brett Porter <brett@apache.org> wrote:
>> It's a valid point. Unfortunately, build profiles can't be used for
>> the distributionManagement section at the moment.
>>
> Hmm...the introduction-to-profiles.html doc seems to suggest that if
> you do it inline (in the POM), you can specify distributionManagement
> in a profile.  Is this an error in the docs, or am I misunderstanding
> something?
>
> Phil
>
>> I believe the solution to this really needs to be server side
>> controls on the repository which we are definitely working on. I'm
>> not sure what we can do on the client side other than education at
>> the moment.
>>
>> - Brett
>>
>> On 30/08/2006, at 4:44 AM, Phil Steitz wrote:
>>
>> > I have one more question / concern with the current setup.
>> >
>> > Currently, we are inheriting the distributionManagement config from
>> > the apache POM.  This seems good and reasonable, except that that
>> > parent defines both apache.snapshots and apache.releases and  
>> points to
>> > the ibiblio synched repo for releases.  That is again good and
>> > natural, but what I am afraid of is what happens when someone
>> > mistakenly changes a <version> not to end in -SNAPSHOT and then  
>> does
>> > "mvn deploy" (or they check in the change and the nightlies do it).
>> > Since (I think) the releases repo lives on the same box
>> > (people.apache.org) that the snapshot one does, authentication  
>> will be
>> > the same and deployment will go to the rsynched repo.  Isn't this
>> > dangerous?  Should we override the distributionManagement  
>> section to
>> > null out the releases section and create a build profile for  
>> releases
>> > that has to be explicitly triggered on the command line?  Will that
>> > work? (i.e., will m2 just merge it in anyway?).
>> >
>> > In m1, we handled this with build properties.  What is the right m2
>> > way to handle this?  I am afraid that the poms I checked in  
>> yesterday
>> > do not handle the risk of accidental deployment correctly.
>> >
>> > Phil
>> >
>> >  
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> > For additional commands, e-mail: commons-dev- 
>> help@jakarta.apache.org
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message