[all][maven 2 configuration]

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[all][maven 2 configuration]

Phil Steitz
IIUC, we currently have an m2 pom hierarchy that goes

for sandbox components:
component -> commons-sandbox -> commons -> jakarta

for "proper" components:
component -> commons -> jakarta
(though only scxml appears to have an m2 build and it does not have a parent)

There are some "vestigal" references in the sandbox to "sandbox-parent."

The commons-sandbox, commons, and jakarta poms are (thanks, Dennis!)
are now published to the m2 snapshot repository.  None of the parent
POMs include the m2 snapshot repository in their repository list,
however, so in order to get the sandbox components that depend on the
hierarchy to build, you need to manually install the parent poms
locally.  This is causing the nightly script to choke when I try to
enable m2 builds.

I suggest that we make the following changes:

1. Add this to the jakarta pom (which gives it some value, assuming
this works ;-)
<repositories>
    <repository>
      <id>apache-snapshots-m1</id>
      <name>Apache Maven 1 Snapshots Repository</name>
      <url>http://people.apache.org/repo/m1-snapshot-repository</url>
      <layout>legacy</layout>
    </repository>
    <repository>
      <id>apache-snapshots-m2</id>
      <name>Apache Maven 2 Snapshots Repository</name>
      <url>http://people.apache.org/repo/m2-snapshot-repository</url>
    </repository>
  </repositories>

2. Add this to the commons parent:

<distributionManagement>
    <snapshotRepository>
      <uniqueVersion>true</uniqueVersion>
      <id>apache.snapshots</id>
       <name>Apache Development Snapshot Repository</name>
    <url>scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository</url>
     </snapshotRepository>
 </distributionManagement>

3. Drop the repo stuff from commons-sandbox

4. Change the sandbox and proper poms to use the hierarchy above.

I am assuming that once these changes are made, "mvn deploy" for a
proper or sandbox component will deploy (assuming ssh is happy) to the
m2 snaps repo.  I need this to work to enable nightlies for m2
components.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][maven 2 configuration]

craigmcc
On 8/27/06, Phil Steitz <[hidden email]> wrote:

>
> IIUC, we currently have an m2 pom hierarchy that goes
>
> for sandbox components:
> component -> commons-sandbox -> commons -> jakarta
>
> for "proper" components:
> component -> commons -> jakarta
> (though only scxml appears to have an m2 build and it does not have a
> parent)
>
> There are some "vestigal" references in the sandbox to "sandbox-parent."
>
> The commons-sandbox, commons, and jakarta poms are (thanks, Dennis!)
> are now published to the m2 snapshot repository.  None of the parent
> POMs include the m2 snapshot repository in their repository list,
> however, so in order to get the sandbox components that depend on the
> hierarchy to build, you need to manually install the parent poms
> locally.  This is causing the nightly script to choke when I try to
> enable m2 builds.
>
> I suggest that we make the following changes:
>
> 1. Add this to the jakarta pom (which gives it some value, assuming
> this works ;-)
> <repositories>
>     <repository>
>       <id>apache-snapshots-m1</id>
>       <name>Apache Maven 1 Snapshots Repository</name>
>       <url>http://people.apache.org/repo/m1-snapshot-repository</url>
>       <layout>legacy</layout>
>     </repository>
>     <repository>
>       <id>apache-snapshots-m2</id>
>       <name>Apache Maven 2 Snapshots Repository</name>
>       <url>http://people.apache.org/repo/m2-snapshot-repository</url>
>     </repository>
>   </repositories>
>
> 2. Add this to the commons parent:
>
> <distributionManagement>
>     <snapshotRepository>
>       <uniqueVersion>true</uniqueVersion>
>       <id>apache.snapshots</id>
>        <name>Apache Development Snapshot Repository</name>
>
>     <url>scp://people.apache.org/www/people.apache.org/repo/m2-snapshot-repository</url>
>      </snapshotRepository>
> </distributionManagement>
>
> 3. Drop the repo stuff from commons-sandbox
>
> 4. Change the sandbox and proper poms to use the hierarchy above.
>
> I am assuming that once these changes are made, "mvn deploy" for a
> proper or sandbox component will deploy (assuming ssh is happy) to the
> m2 snaps repo.  I need this to work to enable nightlies for m2
> components.


From a technology viewpoint, what you're describing sounds like the right
stuff, as long as you use "mvn -N deploy" on the parent POMs so they don't
also publish all the contained modules.

However, it's worth thinking for a minute about the fact that we're
introducing dependencies on those published POMs, so the POMs themselves
should be considered a releaseable artifact subject to a confirming vote.
The Shale and Struts projects do this on changes to the "master" poms, which
play pretty much the same role, and seems like a good idea.

When you take this approach, consider what happens when you've published
version "x" of the commons parent POM, and a new proper project gets added.
You'd want that new project added as a dependency in the version
"y-SNAPSHOT" version of the parent POM, but not mess up the people who are
building based on version "x".

Phil


Craig

Craig
Reply | Threaded
Open this post in threaded view
|

Re: [all][maven 2 configuration]

Wendy Smoak
In reply to this post by Phil Steitz
On 8/27/06, Phil Steitz <[hidden email]> wrote:

> I suggest that we make the following changes:
...

At the top of your pom hierarchy, you can inherit from
org.apache:apache, and you'll pick up the m2 snapshot repo both in
<repositories> and <distributionManagement>.

   http://www.ibiblio.org/maven2/org/apache/apache/3

If you're going to define it again, (for example, to set releases=true
if you're going to deploy non-SNAPSHOT versions there,) then I think
you should keep the id of 'apache.snapshots' so Maven doesn't think
it's a different repository.

--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][maven 2 configuration]

Phil Steitz
On 8/27/06, Wendy Smoak <[hidden email]> wrote:

> On 8/27/06, Phil Steitz <[hidden email]> wrote:
>
> > I suggest that we make the following changes:
> ...
>
> At the top of your pom hierarchy, you can inherit from
> org.apache:apache, and you'll pick up the m2 snapshot repo both in
> <repositories> and <distributionManagement>.
>
>    http://www.ibiblio.org/maven2/org/apache/apache/3
>
> If you're going to define it again, (for example, to set releases=true
> if you're going to deploy non-SNAPSHOT versions there,) then I think
> you should keep the id of 'apache.snapshots' so Maven doesn't think
> it's a different repository.
>

Thanks, Craig and Wendy!

I now think it is best to eliminate the jakarta parent altogether,
since the only use that I can see for it is what's already in the
apache parent.

I also forgot to mention that I would also propose eliminating the
modules from the commons parent(s), partly to avoid the complexities
that Craig points out, but mostly because I don't see either the value
in terms of use cases or the logical basis for this.

I was a naysayer originally on having inheritence at all, but I have
been convinced that it is a *good thing*, so we will just have to make
sure we avoid pitfalls.

And yes, once we have stabilized the commons parent(s), I agree with
need to vote on and release them like other components.

Is it OK, though, to start with components having dependencies to the
-SNAPSHOT versions of the commons parents and then once these are
stable, release them and update the components, using the setup above
to allow them to build in the mean time?  Unless I am missing some
important things (quite likely, unfortunately ;-), we should be able
to get the parent(s) into releasable shape fairly quickly.

Phil
> --
> Wendy
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][maven 2 configuration]

Phil Steitz
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][maven 2 configuration]

Brett Porter-2
It's a valid point. Unfortunately, build profiles can't be used for  
the distributionManagement section at the moment.

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: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][maven 2 configuration]

Phil Steitz
On 8/29/06, Brett Porter <[hidden email]> 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: [hidden email]
> > For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][maven 2 configuration]

Brett Porter-2
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 <[hidden email]> 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: [hidden email]
>> > For additional commands, e-mail: commons-dev-
>> [hidden email]
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][maven 2 configuration]

Phil Steitz
Looks like something like this will actually work (so inline profiles
can override distributionManagement):

<distributionManagement>
    <!-- Null out inherited apache distribution repo by default -->
    <repository>
      <id>dummy</id>
      <name>Dummy to avoid accidental deploys</name>
      <url></url>
    </repository>
  </distributionManagement>
  <profiles>
    <profile>
      <id>release</id>
      <distributionManagement>
        <repository>
          <!-- Activate apache distribution repo -->
          <id>apache.releases</id>
          <name>Apache Release Distribution Repository</name>
          <url>scp://people.apache.org...m2-ibiblio-rsync-repository</url>
        </repository>
      </distributionManagement>
    </profile>
  </profiles>

I checked this locally and using mvn help:effective-pom.  If I add the
above to the commons-parent, then "mvn -Prelease deploy" will work to
deploy and "mvn deploy" will fail if the version is not a snap and it
is trying to deploy to the rsynched repo.  This is a little awkward
and it requires that we maintain the rsynch url in the commons POM,
but it does protect against accidental deploys.  Any better ideas?

I have thought about adding a check to the nightly script to grep out
the version and fail the deploy if it is not a snapshot, but that does
not protect us from other "accidents."  So unless someone has a better
idea, I am inclined to make the change above to the commons-parent
POM.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][maven 2 configuration]

Wendy Smoak
In reply to this post by Phil Steitz
On 8/29/06, Phil Steitz <[hidden email]> wrote:

> I have one more question / concern with the current setup.
>
> Should we override the distributionManagement section to
> null out the releases section ...

We've talked about this some on repository@.  IMO, we need to use a
staging repository for releases and have an easy way to promote a
build from staging to ibiblio-rsync.  (Right now it's hard to move or
copy artifacts between repos, at least if you want the repository
metadata to be somewhat correct.)

Struts and Shale currently have <distributionManagement>/<repository>
pointed at apache.snapshots, while MyFaces uses a staging repo on
their zone.

--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][maven 2 configuration]

Wendy Smoak
In reply to this post by Phil Steitz
On 8/31/06, Phil Steitz <[hidden email]> wrote:

> Looks like something like this will actually work (so inline profiles
> can override distributionManagement):

That looks great. A component can always override
<distributionManagement> if necessary, so this is still flexible.

How and where will you deploy release candidates?  This is something
that doesn't seem to happen now, but I'd like to see Commons RCs
available in a Maven 2 repository.

What about a "rc" profile that points
<distributionManagement>/<repository> to apache.snapshots?  That would
allow a release manager to go through the same process for a release
candidate, except for using -Prc instead of -Prelease.

--
Wendy

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [all][maven 2 configuration]

Phil Steitz
On 8/31/06, Wendy Smoak <[hidden email]> wrote:

> On 8/31/06, Phil Steitz <[hidden email]> wrote:
>
> > Looks like something like this will actually work (so inline profiles
> > can override distributionManagement):
>
> That looks great. A component can always override
> <distributionManagement> if necessary, so this is still flexible.
>
> How and where will you deploy release candidates?  This is something
> that doesn't seem to happen now, but I'd like to see Commons RCs
> available in a Maven 2 repository.
>
> What about a "rc" profile that points
> <distributionManagement>/<repository> to apache.snapshots?  That would
> allow a release manager to go through the same process for a release
> candidate, except for using -Prc instead of -Prelease.
>
Great idea. I will add that too if no one objects / proposes a better
setup than using profiles like this.

Phil

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]