RE: [pre vote take 3] 2.0.9-RC3

[Brian E. Fox]

Sejal, James, could you try with this informal RC? 
http://people.apache.org/~brianf/2.0.9/ (still uploading, give a few mins)

This should get you past MNG-3119 so we can see if everything else is good 
before cutting the RC4 for real. Thanks for testing.

--Brian

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2008 11:07 PM
To: Maven Developers List
Subject: RE: [pre vote take 3] 2.0.9-RC3

It is, we'll respin RC4 in the morning. IMO, 3119 should be permanently 
reverted (in 2.0.x) for the reasons I put in the jira.

-Original Message-
From: Sejal Patel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2008 10:58 PM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

Speaking of which, I just needed to do a release and decided to try doing
the release with maven 2.0.9RC3. Seems like 3119 is not actually fixed
though as I'm running into that problem during the release.  I'm attaching
the console output snipped to the 3119 report. To me this would be a
showstopper ;)


On Wed, Mar 26, 2008 at 10:20 PM, Brian E. Fox <[EMAIL PROTECTED]>
wrote:

> That's ok, locking the plugin versions is actually something I'm not too
> worried about since in all cases we are locking to the currently released
> version, and it's a simple fix in the poms if that causes a problem. I'm
> worried about stuff like James found (MNG-3119).
>
> -Original Message-
> From: Sejal Patel [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2008 9:56 PM
> To: Maven Developers List
> Subject: Re: [pre vote take 3] 2.0.9-RC3
>
> Thanks but it won't be as great a test as you might think though since I
> long ago locked down the plugin version numbers and stuff in a master
> parent
> pom that is used for all projects in the company. So considering that one
> of
> the good things about this release is the lock down of plugin version I
> won't actually have a good way to test that the plugin versions included
> in
> this release are properly tested as well.
>
> On Wed, Mar 26, 2008 at 7:55 PM, Brian E. Fox <[EMAIL PROTECTED]>
> wrote:
>
> > Sejal, thanks...that's exactly the kind of tests we'll need.
> >
> > -Original Message-
> > From: Sejal Patel [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, March 26, 2008 6:47 PM
> > To: Maven Developers List
> > Subject: Re: [pre vote take 3] 2.0.9-RC3
> >
> > +1 for now. Seems to work with my personal projects at home. I'll see
> how
> > well it works on our projects at work and make sure it doesn't break
> > anything that used to work with 2.0.8.
> >
> > I'll give my final answer probably in a little over 24 hours from now
> > (want
> > to make sure it works with all of our projects at work of which we have
> > over
> > 200 of them, several which are reactorized and have 10 or more modules
> to
> > them.).
> >
> >
> > On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni <
> [EMAIL PROTECTED]
> > >
> > wrote:
> >
> > > +1 the bundle worked fine to build
> > > the archetype plugin.
> > >
> > > Raphaël
> > >
> > > 2008/3/26, Raphaël Piéroni <[EMAIL PROTECTED]>:
> > > > +1 for the new process.
> > > >  not yet tested the bundle.
> > > >
> > > >  Raphaël
> > > >
> > > >  2008/3/26, Brian E. Fox <[EMAIL PROTECTED]>:
> > > >
> > > > > We fixed the regressions identified last week with the plugin
> tools
> > > and
> > > >  >  reporting impl. The new 2.0.9 is staged at
> > > >  >
> > > >  >
> > > >  >
> > > >  >
> > >
> http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
> <
> http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa
> >
> > <
> >
> http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa
> > >
> > > >  >  che-maven/2.0.9-RC3/
> > > >  >
> > > >  >
> > > >  >
> > > >  >  You'll notice that this one has an RC qualifier attached to it.
> > > Since
> > > >  >  what I've actually been staging hasn't been for an official
> vote,
> > it
> > > >  >  makes more sense to have actual deterministic numbers on them
> > > instead of
> > > >  >  continuously rolling back and forth between .10 and .9.
> > > >  >
> > > >  >
> > > >  >
> > > >  >  The other significant reason it has a qualifier is that I want
> to
> > > >  >  solicit feedback from the users list without potentially getting
> > > >  >  multiple versions out there called 2.0.9. My new mantra for the
> > > maven
> > > >  >  release is "no more regressions". To that end, what I intend to
> do
> > > is
> > > >  >  let the RC sit here for a day. If no one turns up anything new
> (it
> > > >  >  should be good since this is really attempt #3), then I'll email
> > the
> > > >  >  user list to solicit feedback. Naturally we'll probably get a
> slew
> > > of
> > > >  >  "can you fix xyz" but the only thing that we will consider at
> this
> > > point
> > > >  >  would be a regression from 2.0.8 to the current RC. If something
> > is
>

RE: [pre vote take 3] 2.0.9-RC3

[Brian E. Fox]

It is, we'll respin RC4 in the morning. IMO, 3119 should be permanently 
reverted (in 2.0.x) for the reasons I put in the jira.

-Original Message-
From: Sejal Patel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2008 10:58 PM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

Speaking of which, I just needed to do a release and decided to try doing
the release with maven 2.0.9RC3. Seems like 3119 is not actually fixed
though as I'm running into that problem during the release.  I'm attaching
the console output snipped to the 3119 report. To me this would be a
showstopper ;)


On Wed, Mar 26, 2008 at 10:20 PM, Brian E. Fox <[EMAIL PROTECTED]>
wrote:

> That's ok, locking the plugin versions is actually something I'm not too
> worried about since in all cases we are locking to the currently released
> version, and it's a simple fix in the poms if that causes a problem. I'm
> worried about stuff like James found (MNG-3119).
>
> -Original Message-
> From: Sejal Patel [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2008 9:56 PM
> To: Maven Developers List
> Subject: Re: [pre vote take 3] 2.0.9-RC3
>
> Thanks but it won't be as great a test as you might think though since I
> long ago locked down the plugin version numbers and stuff in a master
> parent
> pom that is used for all projects in the company. So considering that one
> of
> the good things about this release is the lock down of plugin version I
> won't actually have a good way to test that the plugin versions included
> in
> this release are properly tested as well.
>
> On Wed, Mar 26, 2008 at 7:55 PM, Brian E. Fox <[EMAIL PROTECTED]>
> wrote:
>
> > Sejal, thanks...that's exactly the kind of tests we'll need.
> >
> > -Original Message-
> > From: Sejal Patel [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, March 26, 2008 6:47 PM
> > To: Maven Developers List
> > Subject: Re: [pre vote take 3] 2.0.9-RC3
> >
> > +1 for now. Seems to work with my personal projects at home. I'll see
> how
> > well it works on our projects at work and make sure it doesn't break
> > anything that used to work with 2.0.8.
> >
> > I'll give my final answer probably in a little over 24 hours from now
> > (want
> > to make sure it works with all of our projects at work of which we have
> > over
> > 200 of them, several which are reactorized and have 10 or more modules
> to
> > them.).
> >
> >
> > On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni <
> [EMAIL PROTECTED]
> > >
> > wrote:
> >
> > > +1 the bundle worked fine to build
> > > the archetype plugin.
> > >
> > > Raphaël
> > >
> > > 2008/3/26, Raphaël Piéroni <[EMAIL PROTECTED]>:
> > > > +1 for the new process.
> > > >  not yet tested the bundle.
> > > >
> > > >  Raphaël
> > > >
> > > >  2008/3/26, Brian E. Fox <[EMAIL PROTECTED]>:
> > > >
> > > > > We fixed the regressions identified last week with the plugin
> tools
> > > and
> > > >  >  reporting impl. The new 2.0.9 is staged at
> > > >  >
> > > >  >
> > > >  >
> > > >  >
> > >
> http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
> <
> http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa
> >
> > <
> >
> http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa
> > >
> > > >  >  che-maven/2.0.9-RC3/
> > > >  >
> > > >  >
> > > >  >
> > > >  >  You'll notice that this one has an RC qualifier attached to it.
> > > Since
> > > >  >  what I've actually been staging hasn't been for an official
> vote,
> > it
> > > >  >  makes more sense to have actual deterministic numbers on them
> > > instead of
> > > >  >  continuously rolling back and forth between .10 and .9.
> > > >  >
> > > >  >
> > > >  >
> > > >  >  The other significant reason it has a qualifier is that I want
> to
> > > >  >  solicit feedback from the users list without potentially getting
> > > >  >  multiple versions out there called 2.0.9. My new mantra for the
> > > maven
> > > >  >  release is "no more regressions". To that end, what I intend to
> do
> > > is
> > > >  >  let the RC sit here for a day. If no one turns up anything new
> (it
> > > >  >  should be good since this is really attempt #3), then I'll email
> > the
> > > >  >  user list to solicit feedback. Naturally we'll probably get a
> slew
> > > of
> > > >  >  "can you fix xyz" but the only thing that we will consider at
> this
> > > point
> > > >  >  would be a regression from 2.0.8 to the current RC. If something
> > is
> > > >  >  identified then we should consider fixing it and re-releasing
> RC4.
> > I
> > > >  >  think that having the users more involved in testing the RCs is
> > the
> > > only
> > > >  >  way to really identify and eliminate regressions. If someone
> > > identifies
> > > >  >  a regression after the fact and didn't speak up or try it, well
> > > that's
> > > >  >  unfortunate but it'll have to wait.
> > > >  >
> > > >  >
> > > >  >
> > > > 

Re: [pre vote take 3] 2.0.9-RC3

[Sejal Patel]

Speaking of which, I just needed to do a release and decided to try doing
the release with maven 2.0.9RC3. Seems like 3119 is not actually fixed
though as I'm running into that problem during the release.  I'm attaching
the console output snipped to the 3119 report. To me this would be a
showstopper ;)


On Wed, Mar 26, 2008 at 10:20 PM, Brian E. Fox <[EMAIL PROTECTED]>
wrote:

> That's ok, locking the plugin versions is actually something I'm not too
> worried about since in all cases we are locking to the currently released
> version, and it's a simple fix in the poms if that causes a problem. I'm
> worried about stuff like James found (MNG-3119).
>
> -Original Message-
> From: Sejal Patel [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2008 9:56 PM
> To: Maven Developers List
> Subject: Re: [pre vote take 3] 2.0.9-RC3
>
> Thanks but it won't be as great a test as you might think though since I
> long ago locked down the plugin version numbers and stuff in a master
> parent
> pom that is used for all projects in the company. So considering that one
> of
> the good things about this release is the lock down of plugin version I
> won't actually have a good way to test that the plugin versions included
> in
> this release are properly tested as well.
>
> On Wed, Mar 26, 2008 at 7:55 PM, Brian E. Fox <[EMAIL PROTECTED]>
> wrote:
>
> > Sejal, thanks...that's exactly the kind of tests we'll need.
> >
> > -Original Message-
> > From: Sejal Patel [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, March 26, 2008 6:47 PM
> > To: Maven Developers List
> > Subject: Re: [pre vote take 3] 2.0.9-RC3
> >
> > +1 for now. Seems to work with my personal projects at home. I'll see
> how
> > well it works on our projects at work and make sure it doesn't break
> > anything that used to work with 2.0.8.
> >
> > I'll give my final answer probably in a little over 24 hours from now
> > (want
> > to make sure it works with all of our projects at work of which we have
> > over
> > 200 of them, several which are reactorized and have 10 or more modules
> to
> > them.).
> >
> >
> > On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni <
> [EMAIL PROTECTED]
> > >
> > wrote:
> >
> > > +1 the bundle worked fine to build
> > > the archetype plugin.
> > >
> > > Raphaël
> > >
> > > 2008/3/26, Raphaël Piéroni <[EMAIL PROTECTED]>:
> > > > +1 for the new process.
> > > >  not yet tested the bundle.
> > > >
> > > >  Raphaël
> > > >
> > > >  2008/3/26, Brian E. Fox <[EMAIL PROTECTED]>:
> > > >
> > > > > We fixed the regressions identified last week with the plugin
> tools
> > > and
> > > >  >  reporting impl. The new 2.0.9 is staged at
> > > >  >
> > > >  >
> > > >  >
> > > >  >
> > >
> http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
> <
> http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa
> >
> > <
> >
> http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa
> > >
> > > >  >  che-maven/2.0.9-RC3/
> > > >  >
> > > >  >
> > > >  >
> > > >  >  You'll notice that this one has an RC qualifier attached to it.
> > > Since
> > > >  >  what I've actually been staging hasn't been for an official
> vote,
> > it
> > > >  >  makes more sense to have actual deterministic numbers on them
> > > instead of
> > > >  >  continuously rolling back and forth between .10 and .9.
> > > >  >
> > > >  >
> > > >  >
> > > >  >  The other significant reason it has a qualifier is that I want
> to
> > > >  >  solicit feedback from the users list without potentially getting
> > > >  >  multiple versions out there called 2.0.9. My new mantra for the
> > > maven
> > > >  >  release is "no more regressions". To that end, what I intend to
> do
> > > is
> > > >  >  let the RC sit here for a day. If no one turns up anything new
> (it
> > > >  >  should be good since this is really attempt #3), then I'll email
> > the
> > > >  >  user list to solicit feedback. Naturally we'll probably get a
> slew
> > > of
> > > >  >  "can you fix xyz" but the only thing that we will consider at
> this
> > > point
> > > >  >  would be a regression from 2.0.8 to the current RC. If something
> > is
> > > >  >  identified then we should consider fixing it and re-releasing
> RC4.
> > I
> > > >  >  think that having the users more involved in testing the RCs is
> > the
> > > only
> > > >  >  way to really identify and eliminate regressions. If someone
> > > identifies
> > > >  >  a regression after the fact and didn't speak up or try it, well
> > > that's
> > > >  >  unfortunate but it'll have to wait.
> > > >  >
> > > >  >
> > > >  >
> > > >  >  The RC can sit with the users for 3 days. If nothing turns up,
> > then
> > > I'll
> > > >  >  restage with a final release tag and we can do a formal vote.
> > > Assuming
> > > >  >  this is all successful, then I'll document a more formal Core
> > > release
> > > >  >  procedure that we can follow going

RE: [pre vote take 3] 2.0.9-RC3

[Brian E. Fox]

That's ok, locking the plugin versions is actually something I'm not too 
worried about since in all cases we are locking to the currently released 
version, and it's a simple fix in the poms if that causes a problem. I'm 
worried about stuff like James found (MNG-3119).

-Original Message-
From: Sejal Patel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2008 9:56 PM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

Thanks but it won't be as great a test as you might think though since I
long ago locked down the plugin version numbers and stuff in a master parent
pom that is used for all projects in the company. So considering that one of
the good things about this release is the lock down of plugin version I
won't actually have a good way to test that the plugin versions included in
this release are properly tested as well.

On Wed, Mar 26, 2008 at 7:55 PM, Brian E. Fox <[EMAIL PROTECTED]>
wrote:

> Sejal, thanks...that's exactly the kind of tests we'll need.
>
> -Original Message-
> From: Sejal Patel [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2008 6:47 PM
> To: Maven Developers List
> Subject: Re: [pre vote take 3] 2.0.9-RC3
>
> +1 for now. Seems to work with my personal projects at home. I'll see how
> well it works on our projects at work and make sure it doesn't break
> anything that used to work with 2.0.8.
>
> I'll give my final answer probably in a little over 24 hours from now
> (want
> to make sure it works with all of our projects at work of which we have
> over
> 200 of them, several which are reactorized and have 10 or more modules to
> them.).
>
>
> On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni <[EMAIL PROTECTED]
> >
> wrote:
>
> > +1 the bundle worked fine to build
> > the archetype plugin.
> >
> > Raphaël
> >
> > 2008/3/26, Raphaël Piéroni <[EMAIL PROTECTED]>:
> > > +1 for the new process.
> > >  not yet tested the bundle.
> > >
> > >  Raphaël
> > >
> > >  2008/3/26, Brian E. Fox <[EMAIL PROTECTED]>:
> > >
> > > > We fixed the regressions identified last week with the plugin tools
> > and
> > >  >  reporting impl. The new 2.0.9 is staged at
> > >  >
> > >  >
> > >  >
> > >  >
> > http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
> <
> http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa
> >
> > >  >  che-maven/2.0.9-RC3/
> > >  >
> > >  >
> > >  >
> > >  >  You'll notice that this one has an RC qualifier attached to it.
> > Since
> > >  >  what I've actually been staging hasn't been for an official vote,
> it
> > >  >  makes more sense to have actual deterministic numbers on them
> > instead of
> > >  >  continuously rolling back and forth between .10 and .9.
> > >  >
> > >  >
> > >  >
> > >  >  The other significant reason it has a qualifier is that I want to
> > >  >  solicit feedback from the users list without potentially getting
> > >  >  multiple versions out there called 2.0.9. My new mantra for the
> > maven
> > >  >  release is "no more regressions". To that end, what I intend to do
> > is
> > >  >  let the RC sit here for a day. If no one turns up anything new (it
> > >  >  should be good since this is really attempt #3), then I'll email
> the
> > >  >  user list to solicit feedback. Naturally we'll probably get a slew
> > of
> > >  >  "can you fix xyz" but the only thing that we will consider at this
> > point
> > >  >  would be a regression from 2.0.8 to the current RC. If something
> is
> > >  >  identified then we should consider fixing it and re-releasing RC4.
> I
> > >  >  think that having the users more involved in testing the RCs is
> the
> > only
> > >  >  way to really identify and eliminate regressions. If someone
> > identifies
> > >  >  a regression after the fact and didn't speak up or try it, well
> > that's
> > >  >  unfortunate but it'll have to wait.
> > >  >
> > >  >
> > >  >
> > >  >  The RC can sit with the users for 3 days. If nothing turns up,
> then
> > I'll
> > >  >  restage with a final release tag and we can do a formal vote.
> > Assuming
> > >  >  this is all successful, then I'll document a more formal Core
> > release
> > >  >  procedure that we can follow going forward.
> > >  >
> > >  >
> > >  >
> > >  >  Here's the list of issues fixed in the latest RC:
> > >  >
> > >  >
> > >  >
> > >  >  Release Notes - Maven 2 - Version 2.0.9
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >  ** Bug
> > >  >
> > >  > * [MNG-1412] - dependency sorting in classpath
> > >  >
> > >  > * [MNG-1914] - Wrong url in error message when using a mirror
> > >  >
> > >  > * [MNG-2123] - NullPointerException when a dependency uses
> > version
> > >  >  range and another uses an actual version incompatible with that
> > range
> > >  >
> > >  > * [MNG-2145] - Plugins' dependencies are not always checked
> > >  >
> > >  > * [MNG-2178] - incorrect M2_HOME guess in mvn.bat
> > >  >

Re: [pre vote take 3] 2.0.9-RC3

[Sejal Patel]

Thanks but it won't be as great a test as you might think though since I
long ago locked down the plugin version numbers and stuff in a master parent
pom that is used for all projects in the company. So considering that one of
the good things about this release is the lock down of plugin version I
won't actually have a good way to test that the plugin versions included in
this release are properly tested as well.

On Wed, Mar 26, 2008 at 7:55 PM, Brian E. Fox <[EMAIL PROTECTED]>
wrote:

> Sejal, thanks...that's exactly the kind of tests we'll need.
>
> -Original Message-
> From: Sejal Patel [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, March 26, 2008 6:47 PM
> To: Maven Developers List
> Subject: Re: [pre vote take 3] 2.0.9-RC3
>
> +1 for now. Seems to work with my personal projects at home. I'll see how
> well it works on our projects at work and make sure it doesn't break
> anything that used to work with 2.0.8.
>
> I'll give my final answer probably in a little over 24 hours from now
> (want
> to make sure it works with all of our projects at work of which we have
> over
> 200 of them, several which are reactorized and have 10 or more modules to
> them.).
>
>
> On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni <[EMAIL PROTECTED]
> >
> wrote:
>
> > +1 the bundle worked fine to build
> > the archetype plugin.
> >
> > Raphaël
> >
> > 2008/3/26, Raphaël Piéroni <[EMAIL PROTECTED]>:
> > > +1 for the new process.
> > >  not yet tested the bundle.
> > >
> > >  Raphaël
> > >
> > >  2008/3/26, Brian E. Fox <[EMAIL PROTECTED]>:
> > >
> > > > We fixed the regressions identified last week with the plugin tools
> > and
> > >  >  reporting impl. The new 2.0.9 is staged at
> > >  >
> > >  >
> > >  >
> > >  >
> > http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
> <
> http://people.apache.org/%7Ebrianf/staging-repository/org/apache/maven/apa
> >
> > >  >  che-maven/2.0.9-RC3/
> > >  >
> > >  >
> > >  >
> > >  >  You'll notice that this one has an RC qualifier attached to it.
> > Since
> > >  >  what I've actually been staging hasn't been for an official vote,
> it
> > >  >  makes more sense to have actual deterministic numbers on them
> > instead of
> > >  >  continuously rolling back and forth between .10 and .9.
> > >  >
> > >  >
> > >  >
> > >  >  The other significant reason it has a qualifier is that I want to
> > >  >  solicit feedback from the users list without potentially getting
> > >  >  multiple versions out there called 2.0.9. My new mantra for the
> > maven
> > >  >  release is "no more regressions". To that end, what I intend to do
> > is
> > >  >  let the RC sit here for a day. If no one turns up anything new (it
> > >  >  should be good since this is really attempt #3), then I'll email
> the
> > >  >  user list to solicit feedback. Naturally we'll probably get a slew
> > of
> > >  >  "can you fix xyz" but the only thing that we will consider at this
> > point
> > >  >  would be a regression from 2.0.8 to the current RC. If something
> is
> > >  >  identified then we should consider fixing it and re-releasing RC4.
> I
> > >  >  think that having the users more involved in testing the RCs is
> the
> > only
> > >  >  way to really identify and eliminate regressions. If someone
> > identifies
> > >  >  a regression after the fact and didn't speak up or try it, well
> > that's
> > >  >  unfortunate but it'll have to wait.
> > >  >
> > >  >
> > >  >
> > >  >  The RC can sit with the users for 3 days. If nothing turns up,
> then
> > I'll
> > >  >  restage with a final release tag and we can do a formal vote.
> > Assuming
> > >  >  this is all successful, then I'll document a more formal Core
> > release
> > >  >  procedure that we can follow going forward.
> > >  >
> > >  >
> > >  >
> > >  >  Here's the list of issues fixed in the latest RC:
> > >  >
> > >  >
> > >  >
> > >  >  Release Notes - Maven 2 - Version 2.0.9
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >  ** Bug
> > >  >
> > >  > * [MNG-1412] - dependency sorting in classpath
> > >  >
> > >  > * [MNG-1914] - Wrong url in error message when using a mirror
> > >  >
> > >  > * [MNG-2123] - NullPointerException when a dependency uses
> > version
> > >  >  range and another uses an actual version incompatible with that
> > range
> > >  >
> > >  > * [MNG-2145] - Plugins' dependencies are not always checked
> > >  >
> > >  > * [MNG-2178] - incorrect M2_HOME guess in mvn.bat
> > >  >
> > >  > * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored
> > when
> > >  >  profiles section is missing or empty
> > >  >
> > >  > * [MNG-2339] - ${project.*} are interpreted in the wrong place
> > >  >
> > >  > * [MNG-2744] - checksum comparison should be case-insensitive
> > >  >
> > >  > * [MNG-2809] - Can't activate a profile by checking for the
> > presence
> > >  >  of a file in ${user.home}
> > >  >
> > >  > 

RE: [pre vote take 3] 2.0.9-RC3

[James William Dumay]

Ill also build all of Atlassians products with the RC3 today and post
some results to the list

James

On Wed, 2008-03-26 at 19:55 -0400, Brian E. Fox wrote:
> Sejal, thanks...that's exactly the kind of tests we'll need.
> 
> -Original Message-
> From: Sejal Patel [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, March 26, 2008 6:47 PM
> To: Maven Developers List
> Subject: Re: [pre vote take 3] 2.0.9-RC3
> 
> +1 for now. Seems to work with my personal projects at home. I'll see how
> well it works on our projects at work and make sure it doesn't break
> anything that used to work with 2.0.8.
> 
> I'll give my final answer probably in a little over 24 hours from now (want
> to make sure it works with all of our projects at work of which we have over
> 200 of them, several which are reactorized and have 10 or more modules to
> them.).
> 
> 
> On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni <[EMAIL PROTECTED]>
> wrote:
> 
> > +1 the bundle worked fine to build
> > the archetype plugin.
> >
> > Raphaël
> >
> > 2008/3/26, Raphaël Piéroni <[EMAIL PROTECTED]>:
> > > +1 for the new process.
> > >  not yet tested the bundle.
> > >
> > >  Raphaël
> > >
> > >  2008/3/26, Brian E. Fox <[EMAIL PROTECTED]>:
> > >
> > > > We fixed the regressions identified last week with the plugin tools
> > and
> > >  >  reporting impl. The new 2.0.9 is staged at
> > >  >
> > >  >
> > >  >
> > >  >
> > http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
> > >  >  che-maven/2.0.9-RC3/
> > >  >
> > >  >
> > >  >
> > >  >  You'll notice that this one has an RC qualifier attached to it.
> > Since
> > >  >  what I've actually been staging hasn't been for an official vote, it
> > >  >  makes more sense to have actual deterministic numbers on them
> > instead of
> > >  >  continuously rolling back and forth between .10 and .9.
> > >  >
> > >  >
> > >  >
> > >  >  The other significant reason it has a qualifier is that I want to
> > >  >  solicit feedback from the users list without potentially getting
> > >  >  multiple versions out there called 2.0.9. My new mantra for the
> > maven
> > >  >  release is "no more regressions". To that end, what I intend to do
> > is
> > >  >  let the RC sit here for a day. If no one turns up anything new (it
> > >  >  should be good since this is really attempt #3), then I'll email the
> > >  >  user list to solicit feedback. Naturally we'll probably get a slew
> > of
> > >  >  "can you fix xyz" but the only thing that we will consider at this
> > point
> > >  >  would be a regression from 2.0.8 to the current RC. If something is
> > >  >  identified then we should consider fixing it and re-releasing RC4. I
> > >  >  think that having the users more involved in testing the RCs is the
> > only
> > >  >  way to really identify and eliminate regressions. If someone
> > identifies
> > >  >  a regression after the fact and didn't speak up or try it, well
> > that's
> > >  >  unfortunate but it'll have to wait.
> > >  >
> > >  >
> > >  >
> > >  >  The RC can sit with the users for 3 days. If nothing turns up, then
> > I'll
> > >  >  restage with a final release tag and we can do a formal vote.
> > Assuming
> > >  >  this is all successful, then I'll document a more formal Core
> > release
> > >  >  procedure that we can follow going forward.
> > >  >
> > >  >
> > >  >
> > >  >  Here's the list of issues fixed in the latest RC:
> > >  >
> > >  >
> > >  >
> > >  >  Release Notes - Maven 2 - Version 2.0.9
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >
> > >  >  ** Bug
> > >  >
> > >  > * [MNG-1412] - dependency sorting in classpath
> > >  >
> > >  > * [MNG-1914] - Wrong url in error message when using a mirror
> > >  >
> > >  > * [MNG-2123] - NullPointerException when a dependency uses
> > version
> > >  >  range and another uses an actual version incompatible with that
> > range
> > >  >
> > >  > * [MNG-2145] - Plugins' dependencies are not always checked
> > >  >
> > >  > * [MNG-2178] - incorrect M2_HOME guess in mvn.bat
> > >  >
> > >  > * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored
> > when
> > >  >  profiles section is missing or empty
> > >  >
> > >  > * [MNG-2339] - ${project.*} are interpreted in the wrong place
> > >  >
> > >  > * [MNG-2744] - checksum comparison should be case-insensitive
> > >  >
> > >  > * [MNG-2809] - Can't activate a profile by checking for the
> > presence
> > >  >  of a file in ${user.home}
> > >  >
> > >  > * [MNG-2848] - Environment variables in profile activation not
> > >  >  working
> > >  >
> > >  > * [MNG-2861] - NullPointerException in DefaultArtifactCollector
> > for
> > >  >  relocated resolvedArtifacts with different version ranges and
> > available
> > >  >  versions.
> > >  >
> > >  > * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo()
> > if
> > >  >  there's no mojo in pom.xml
> > >  >
> > >  > 

RE: [pre vote take 3] 2.0.9-RC3

[Brian E. Fox]

Sejal, thanks...that's exactly the kind of tests we'll need.

-Original Message-
From: Sejal Patel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2008 6:47 PM
To: Maven Developers List
Subject: Re: [pre vote take 3] 2.0.9-RC3

+1 for now. Seems to work with my personal projects at home. I'll see how
well it works on our projects at work and make sure it doesn't break
anything that used to work with 2.0.8.

I'll give my final answer probably in a little over 24 hours from now (want
to make sure it works with all of our projects at work of which we have over
200 of them, several which are reactorized and have 10 or more modules to
them.).


On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni <[EMAIL PROTECTED]>
wrote:

> +1 the bundle worked fine to build
> the archetype plugin.
>
> Raphaël
>
> 2008/3/26, Raphaël Piéroni <[EMAIL PROTECTED]>:
> > +1 for the new process.
> >  not yet tested the bundle.
> >
> >  Raphaël
> >
> >  2008/3/26, Brian E. Fox <[EMAIL PROTECTED]>:
> >
> > > We fixed the regressions identified last week with the plugin tools
> and
> >  >  reporting impl. The new 2.0.9 is staged at
> >  >
> >  >
> >  >
> >  >
> http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
> >  >  che-maven/2.0.9-RC3/
> >  >
> >  >
> >  >
> >  >  You'll notice that this one has an RC qualifier attached to it.
> Since
> >  >  what I've actually been staging hasn't been for an official vote, it
> >  >  makes more sense to have actual deterministic numbers on them
> instead of
> >  >  continuously rolling back and forth between .10 and .9.
> >  >
> >  >
> >  >
> >  >  The other significant reason it has a qualifier is that I want to
> >  >  solicit feedback from the users list without potentially getting
> >  >  multiple versions out there called 2.0.9. My new mantra for the
> maven
> >  >  release is "no more regressions". To that end, what I intend to do
> is
> >  >  let the RC sit here for a day. If no one turns up anything new (it
> >  >  should be good since this is really attempt #3), then I'll email the
> >  >  user list to solicit feedback. Naturally we'll probably get a slew
> of
> >  >  "can you fix xyz" but the only thing that we will consider at this
> point
> >  >  would be a regression from 2.0.8 to the current RC. If something is
> >  >  identified then we should consider fixing it and re-releasing RC4. I
> >  >  think that having the users more involved in testing the RCs is the
> only
> >  >  way to really identify and eliminate regressions. If someone
> identifies
> >  >  a regression after the fact and didn't speak up or try it, well
> that's
> >  >  unfortunate but it'll have to wait.
> >  >
> >  >
> >  >
> >  >  The RC can sit with the users for 3 days. If nothing turns up, then
> I'll
> >  >  restage with a final release tag and we can do a formal vote.
> Assuming
> >  >  this is all successful, then I'll document a more formal Core
> release
> >  >  procedure that we can follow going forward.
> >  >
> >  >
> >  >
> >  >  Here's the list of issues fixed in the latest RC:
> >  >
> >  >
> >  >
> >  >  Release Notes - Maven 2 - Version 2.0.9
> >  >
> >  >
> >  >
> >  >
> >  >
> >  >  ** Bug
> >  >
> >  > * [MNG-1412] - dependency sorting in classpath
> >  >
> >  > * [MNG-1914] - Wrong url in error message when using a mirror
> >  >
> >  > * [MNG-2123] - NullPointerException when a dependency uses
> version
> >  >  range and another uses an actual version incompatible with that
> range
> >  >
> >  > * [MNG-2145] - Plugins' dependencies are not always checked
> >  >
> >  > * [MNG-2178] - incorrect M2_HOME guess in mvn.bat
> >  >
> >  > * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored
> when
> >  >  profiles section is missing or empty
> >  >
> >  > * [MNG-2339] - ${project.*} are interpreted in the wrong place
> >  >
> >  > * [MNG-2744] - checksum comparison should be case-insensitive
> >  >
> >  > * [MNG-2809] - Can't activate a profile by checking for the
> presence
> >  >  of a file in ${user.home}
> >  >
> >  > * [MNG-2848] - Environment variables in profile activation not
> >  >  working
> >  >
> >  > * [MNG-2861] - NullPointerException in DefaultArtifactCollector
> for
> >  >  relocated resolvedArtifacts with different version ranges and
> available
> >  >  versions.
> >  >
> >  > * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo()
> if
> >  >  there's no mojo in pom.xml
> >  >
> >  > * [MNG-2928] - Null pointer exeception when introducing version
> >  >  range [major.minor.build-SNAPSHOT,)
> >  >
> >  > * [MNG-2972] - Ignores version of plugin dependency specified in
> my
> >  >  pom
> >  >
> >  > * [MNG-3086] - NullPointerException in
> >  >  ResolutionNode.getTrail(ResolutionNode.java:136)
> >  >
> >  > * [MNG-3099] - Profiles ignored when working with non-projects
> (such
> >  >  as archetype:cr

Re: [pre vote take 3] 2.0.9-RC3

[Sejal Patel]

+1 for now. Seems to work with my personal projects at home. I'll see how
well it works on our projects at work and make sure it doesn't break
anything that used to work with 2.0.8.

I'll give my final answer probably in a little over 24 hours from now (want
to make sure it works with all of our projects at work of which we have over
200 of them, several which are reactorized and have 10 or more modules to
them.).


On Wed, Mar 26, 2008 at 5:27 PM, Raphaël Piéroni <[EMAIL PROTECTED]>
wrote:

> +1 the bundle worked fine to build
> the archetype plugin.
>
> Raphaël
>
> 2008/3/26, Raphaël Piéroni <[EMAIL PROTECTED]>:
> > +1 for the new process.
> >  not yet tested the bundle.
> >
> >  Raphaël
> >
> >  2008/3/26, Brian E. Fox <[EMAIL PROTECTED]>:
> >
> > > We fixed the regressions identified last week with the plugin tools
> and
> >  >  reporting impl. The new 2.0.9 is staged at
> >  >
> >  >
> >  >
> >  >
> http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
> >  >  che-maven/2.0.9-RC3/
> >  >
> >  >
> >  >
> >  >  You'll notice that this one has an RC qualifier attached to it.
> Since
> >  >  what I've actually been staging hasn't been for an official vote, it
> >  >  makes more sense to have actual deterministic numbers on them
> instead of
> >  >  continuously rolling back and forth between .10 and .9.
> >  >
> >  >
> >  >
> >  >  The other significant reason it has a qualifier is that I want to
> >  >  solicit feedback from the users list without potentially getting
> >  >  multiple versions out there called 2.0.9. My new mantra for the
> maven
> >  >  release is "no more regressions". To that end, what I intend to do
> is
> >  >  let the RC sit here for a day. If no one turns up anything new (it
> >  >  should be good since this is really attempt #3), then I'll email the
> >  >  user list to solicit feedback. Naturally we'll probably get a slew
> of
> >  >  "can you fix xyz" but the only thing that we will consider at this
> point
> >  >  would be a regression from 2.0.8 to the current RC. If something is
> >  >  identified then we should consider fixing it and re-releasing RC4. I
> >  >  think that having the users more involved in testing the RCs is the
> only
> >  >  way to really identify and eliminate regressions. If someone
> identifies
> >  >  a regression after the fact and didn't speak up or try it, well
> that's
> >  >  unfortunate but it'll have to wait.
> >  >
> >  >
> >  >
> >  >  The RC can sit with the users for 3 days. If nothing turns up, then
> I'll
> >  >  restage with a final release tag and we can do a formal vote.
> Assuming
> >  >  this is all successful, then I'll document a more formal Core
> release
> >  >  procedure that we can follow going forward.
> >  >
> >  >
> >  >
> >  >  Here's the list of issues fixed in the latest RC:
> >  >
> >  >
> >  >
> >  >  Release Notes - Maven 2 - Version 2.0.9
> >  >
> >  >
> >  >
> >  >
> >  >
> >  >  ** Bug
> >  >
> >  > * [MNG-1412] - dependency sorting in classpath
> >  >
> >  > * [MNG-1914] - Wrong url in error message when using a mirror
> >  >
> >  > * [MNG-2123] - NullPointerException when a dependency uses
> version
> >  >  range and another uses an actual version incompatible with that
> range
> >  >
> >  > * [MNG-2145] - Plugins' dependencies are not always checked
> >  >
> >  > * [MNG-2178] - incorrect M2_HOME guess in mvn.bat
> >  >
> >  > * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored
> when
> >  >  profiles section is missing or empty
> >  >
> >  > * [MNG-2339] - ${project.*} are interpreted in the wrong place
> >  >
> >  > * [MNG-2744] - checksum comparison should be case-insensitive
> >  >
> >  > * [MNG-2809] - Can't activate a profile by checking for the
> presence
> >  >  of a file in ${user.home}
> >  >
> >  > * [MNG-2848] - Environment variables in profile activation not
> >  >  working
> >  >
> >  > * [MNG-2861] - NullPointerException in DefaultArtifactCollector
> for
> >  >  relocated resolvedArtifacts with different version ranges and
> available
> >  >  versions.
> >  >
> >  > * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo()
> if
> >  >  there's no mojo in pom.xml
> >  >
> >  > * [MNG-2928] - Null pointer exeception when introducing version
> >  >  range [major.minor.build-SNAPSHOT,)
> >  >
> >  > * [MNG-2972] - Ignores version of plugin dependency specified in
> my
> >  >  pom
> >  >
> >  > * [MNG-3086] - NullPointerException in
> >  >  ResolutionNode.getTrail(ResolutionNode.java:136)
> >  >
> >  > * [MNG-3099] - Profiles ignored when working with non-projects
> (such
> >  >  as archetype:create)
> >  >
> >  > * [MNG-3111] - Classpath order incorrect
> >  >
> >  > * [MNG-3156] - NullPointerException with mvn dependency:sources
> >  >
> >  > * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor
> >  >
> >  > * 

Re: svn commit: r640193 - /maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report.properties

[Dennis Lundberg]

I see it as an unfortunate side effect. I'd much rather have a good 
descriptive name, running across 2 lines, than a strained abbreviation 
on 1 line.


Vincent Siveton wrote:

Hi Dennis,

"Dependency Management" is now on 2 lines in the nav bar. Is it the
wanted behaviour?

Cheers,

Vincent

2008/3/23, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:

Author: dennisl
 Date: Sun Mar 23 05:38:42 2008
 New Revision: 640193

 URL: http://svn.apache.org/viewvc?rev=640193&view=rev
 Log:
 o Add a proper name and description for report.dependencyManagement and 
report.pluginManagement.
 o Fix typos.

 Modified:

maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report.properties

 Modified: 
maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report.properties
 URL: 
http://svn.apache.org/viewvc/maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report.properties?rev=640193&r1=640192&r2=640193&view=diff
 ==
 --- 
maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report.properties
 (original)
 +++ 
maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report.properties
 Sun Mar 23 05:38:42 2008
 @@ -144,8 +144,8 @@
  report.scm.description = This is 
a link to the online source repository that can be viewed via a web browser.
  report.scm.devaccess.clearcase.intro   = Only 
project developers can access the ClearCase tree via this method. Substitute 
username with the proper value.
  report.scm.devaccess.cvs.intro = Only 
project developers can access the CVS tree via this method. Substitute username 
with the proper value.
 -report.scm.devaccess.general.intro = Refer to 
the documentation of the SCM used for more information about developer checked 
out. The connection url is:
 -report.scm.devaccess.perforce.intro= Only 
project developers can access the Perforce tree via this method. Substitute 
username and password with the proper value.
 +report.scm.devaccess.general.intro = Refer to 
the documentation of the SCM used for more information about developer check 
out. The connection url is:
 +report.scm.devaccess.perforce.intro= Only 
project developers can access the Perforce tree via this method. Substitute 
username and password with the proper values.
  report.scm.devaccess.starteam.intro= Only 
project developers can access the Starteam tree via this method. Substitute 
username with the proper value.
  report.scm.devaccess.svn.intro1.https  = Everyone 
can access the Subversion repository via HTTPS, but Committers must checkout 
the Subversion repository via HTTPS.
  report.scm.devaccess.svn.intro1.other  = 
Committers must checkout the Subversion repository.
 @@ -216,8 +216,8 @@
  report.transitivedependencies.intro= The 
following is a list of transitive dependencies for this project. Transitive 
dependencies are the dependencies of the project dependencies.
  report.transitivedependencies.nolist   = No 
transitive dependencies are required for this project.
  report.transitivedependencies.title= Project 
Transitive Dependencies
 -report.dependencyManagement.name   = 
Dependency Mngt
 -report.dependencyManagement.description= 
description
 +report.dependencyManagement.name   = 
Dependency Management
 +report.dependencyManagement.description= This 
document lists the dependencies that are defined through dependencyManagement.
  report.dependencyManagement.title  = Project 
Dependency Management
  report.dependencyManagement.nolist = There 
are no dependencies in the DependencyManagement of this project.
  report.dependencyManagement.column.groupId = GroupId
 @@ -230,7 +230,7 @@
  report.dependencyManagement.intro.runtime  = The 
following is a list of runtime dependencies in the DependencyManagement of this 
project. These dependencies can be included in the submodules to run the 
submodule:
  report.dependencyManagement.intro.system   = The 
following is a list of system dependencies in the DependencyManagement of this 
project. These dependencies can be included in the submodules to compile the 
submodule:
  report.dependencyManagement.intro.test = The 
following is a list of 

RE: svn commit: r634131 - in /maven/core-integration-testing/trunk/core-integration-tests/src/test: java/org/apache/maven/integrationtests/ resources/mng-3341-metadataUpdatedFromDeploymentRepository/

[Brian E. Fox]

I would prefer to keep the names more descriptive than just the number.
When you're working with a bunch, it's hard to remember the exact number
sometimes.

-Original Message-
From: Brett Porter [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2008 5:27 PM
To: Maven Developers List
Subject: Re: svn commit: r634131 - in
/maven/core-integration-testing/trunk/core-integration-tests/src/test:
java/org/apache/maven/integrationtests/
resources/mng-3341-metadataUpdatedFromDeploymentRepository/
resources/mng-3341-metadataUpdatedFromDeploymentRe

I don't think the names are the problem - it's the repositories within  
the tests that are.

I was going to try removing them and creating the artifacts in the  
repository as part of the unit test.

- Brett

On 26/03/2008, at 11:54 PM, Vincent Siveton wrote:

> Hi,
>
> I am happy to work on this. I propose to rename IT resources like  
> the following:
> mng-3341-metadataUpdatedFromDeploymentRepository -> mng-3341
> And adding a README or a pom description inside the dir.
>
> Cheers,
>
> Vincent
>
> 2008/3/11, Brett Porter <[EMAIL PROTECTED]>:
>> Yeah, I noticed this on some others too. I'm going to have a go at
>> getting this all in line now.
>>
>> - Brett
>>
>>
>> On 12/03/2008, at 8:26 AM, Vincent Siveton wrote:
>>
>>> Hi Brett,
>>>
>>> Could you reduce the dir names for
>>> mng-3341-metadataUpdatedFromDeploymentRepository?
>>>
>>> I am unable to do an update on windows ...
>>>
>>> Thanks.
>>>
>>> Vincent
>>>
>>> 2008/3/5, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
 Author: brett
 Date: Wed Mar  5 18:35:59 2008
 New Revision: 634131

 URL: http://svn.apache.org/viewvc?rev=634131&view=rev
 Log:
 [MNG-3341] only look in the original deployment repository for
 metadata to update

 Added:
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/java/org/apache/maven/integrationtests/
 MavenITmng3341MetadataUpdatedFromDeploymentRepositoryTest.java
 - copied, changed from r633736, maven/core-integration-testing/
 trunk/core-integration-tests/src/test/java/org/apache/maven/
 integrationtests/MavenITmng2234ActiveProfilesFromSettingsTest.java
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
 deployment-repository/
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
 deployment-repository/org/
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
 deployment-repository/org/apache/
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
 deployment-repository/org/apache/maven/
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
 deployment-repository/org/apache/maven/its/
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
 deployment-repository/org/apache/maven/its/mng3341/
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
 deployment-repository/org/apache/maven/its/mng3341/maven-
 metadata.xml   (with props)
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
 deployment-repository/org/apache/maven/its/mng3341/maven-
 metadata.xml.md5
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
 deployment-repository/org/apache/maven/its/mng3341/maven-
 metadata.xml.sha1
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
 deployment-repository/org/apache/maven/its/mng3341/test-artifact/
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
 deployment-repository/org/apache/maven/its/mng3341/test-artifact/
 1.0-SNAPSHOT/
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
 deployment-repository/org/apache/maven/its/mng3341/test-artifact/
 1.0-SNAPSHOT/maven-metadata.xml   (with props)
   maven/core-integration-testing/trunk/core-integration-tests/src/
 test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
 d

Re: [pre vote take 3] 2.0.9-RC3

[Raphaël Piéroni]

+1 the bundle worked fine to build
the archetype plugin.

Raphaël

2008/3/26, Raphaël Piéroni <[EMAIL PROTECTED]>:
> +1 for the new process.
>  not yet tested the bundle.
>
>  Raphaël
>
>  2008/3/26, Brian E. Fox <[EMAIL PROTECTED]>:
>
> > We fixed the regressions identified last week with the plugin tools and
>  >  reporting impl. The new 2.0.9 is staged at
>  >
>  >
>  >
>  >  http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
>  >  che-maven/2.0.9-RC3/
>  >
>  >
>  >
>  >  You'll notice that this one has an RC qualifier attached to it. Since
>  >  what I've actually been staging hasn't been for an official vote, it
>  >  makes more sense to have actual deterministic numbers on them instead of
>  >  continuously rolling back and forth between .10 and .9.
>  >
>  >
>  >
>  >  The other significant reason it has a qualifier is that I want to
>  >  solicit feedback from the users list without potentially getting
>  >  multiple versions out there called 2.0.9. My new mantra for the maven
>  >  release is "no more regressions". To that end, what I intend to do is
>  >  let the RC sit here for a day. If no one turns up anything new (it
>  >  should be good since this is really attempt #3), then I'll email the
>  >  user list to solicit feedback. Naturally we'll probably get a slew of
>  >  "can you fix xyz" but the only thing that we will consider at this point
>  >  would be a regression from 2.0.8 to the current RC. If something is
>  >  identified then we should consider fixing it and re-releasing RC4. I
>  >  think that having the users more involved in testing the RCs is the only
>  >  way to really identify and eliminate regressions. If someone identifies
>  >  a regression after the fact and didn't speak up or try it, well that's
>  >  unfortunate but it'll have to wait.
>  >
>  >
>  >
>  >  The RC can sit with the users for 3 days. If nothing turns up, then I'll
>  >  restage with a final release tag and we can do a formal vote. Assuming
>  >  this is all successful, then I'll document a more formal Core release
>  >  procedure that we can follow going forward.
>  >
>  >
>  >
>  >  Here's the list of issues fixed in the latest RC:
>  >
>  >
>  >
>  >  Release Notes - Maven 2 - Version 2.0.9
>  >
>  >
>  >
>  >
>  >
>  >  ** Bug
>  >
>  > * [MNG-1412] - dependency sorting in classpath
>  >
>  > * [MNG-1914] - Wrong url in error message when using a mirror
>  >
>  > * [MNG-2123] - NullPointerException when a dependency uses version
>  >  range and another uses an actual version incompatible with that range
>  >
>  > * [MNG-2145] - Plugins' dependencies are not always checked
>  >
>  > * [MNG-2178] - incorrect M2_HOME guess in mvn.bat
>  >
>  > * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
>  >  profiles section is missing or empty
>  >
>  > * [MNG-2339] - ${project.*} are interpreted in the wrong place
>  >
>  > * [MNG-2744] - checksum comparison should be case-insensitive
>  >
>  > * [MNG-2809] - Can't activate a profile by checking for the presence
>  >  of a file in ${user.home}
>  >
>  > * [MNG-2848] - Environment variables in profile activation not
>  >  working
>  >
>  > * [MNG-2861] - NullPointerException in DefaultArtifactCollector for
>  >  relocated resolvedArtifacts with different version ranges and available
>  >  versions.
>  >
>  > * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if
>  >  there's no mojo in pom.xml
>  >
>  > * [MNG-2928] - Null pointer exeception when introducing version
>  >  range [major.minor.build-SNAPSHOT,)
>  >
>  > * [MNG-2972] - Ignores version of plugin dependency specified in my
>  >  pom
>  >
>  > * [MNG-3086] - NullPointerException in
>  >  ResolutionNode.getTrail(ResolutionNode.java:136)
>  >
>  > * [MNG-3099] - Profiles ignored when working with non-projects (such
>  >  as archetype:create)
>  >
>  > * [MNG-3111] - Classpath order incorrect
>  >
>  > * [MNG-3156] - NullPointerException with mvn dependency:sources
>  >
>  > * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor
>  >
>  > * [MNG-3259] - Regression: Maven drops dependencies in multi-module
>  >  build
>  >
>  > * [MNG-3286] - execution.inherited field is ignored
>  >
>  > * [MNG-3288] - Invalid systemPath allows build to continue--failing
>  >  in later phase.
>  >
>  > * [MNG-3296] - mvn.bat looses error code on windows NT type
>  >  platforms
>  >
>  > * [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set
>  >
>  > * [MNG-3316] - Barfs at attribues named .*encoding
>  >
>  > * [MNG-3354] - mvn.bat incorrectly detects OS on Windows NT or XP
>  >  with Novell login
>  >
>  > * [MNG-3355] - CLONE -${pom.build.sourceDirectory} and
>  >  ${pom.build.testSourceDirectory} no longer recognized
>  >
>  > * [MNG-3365] - Remove trailing-backslashes from M2_HOME in mvn.bat
>  >
>  > * [MNG-3394] - Plugin versions inherit

Re: svn commit: r634131 - in /maven/core-integration-testing/trunk/core-integration-tests/src/test: java/org/apache/maven/integrationtests/ resources/mng-3341-metadataUpdatedFromDeploymentRepository/

[Brett Porter]

I don't think the names are the problem - it's the repositories within  
the tests that are.


I was going to try removing them and creating the artifacts in the  
repository as part of the unit test.


- Brett

On 26/03/2008, at 11:54 PM, Vincent Siveton wrote:


Hi,

I am happy to work on this. I propose to rename IT resources like  
the following:

mng-3341-metadataUpdatedFromDeploymentRepository -> mng-3341
And adding a README or a pom description inside the dir.

Cheers,

Vincent

2008/3/11, Brett Porter <[EMAIL PROTECTED]>:

Yeah, I noticed this on some others too. I'm going to have a go at
getting this all in line now.

- Brett


On 12/03/2008, at 8:26 AM, Vincent Siveton wrote:


Hi Brett,

Could you reduce the dir names for
mng-3341-metadataUpdatedFromDeploymentRepository?

I am unable to do an update on windows ...

Thanks.

Vincent

2008/3/5, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:

Author: brett
Date: Wed Mar  5 18:35:59 2008
New Revision: 634131

URL: http://svn.apache.org/viewvc?rev=634131&view=rev
Log:
[MNG-3341] only look in the original deployment repository for
metadata to update

Added:
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/java/org/apache/maven/integrationtests/
MavenITmng3341MetadataUpdatedFromDeploymentRepositoryTest.java
- copied, changed from r633736, maven/core-integration-testing/
trunk/core-integration-tests/src/test/java/org/apache/maven/
integrationtests/MavenITmng2234ActiveProfilesFromSettingsTest.java
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/maven/
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/maven/its/
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/maven/its/mng3341/
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/maven/its/mng3341/maven-
metadata.xml   (with props)
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/maven/its/mng3341/maven-
metadata.xml.md5
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/maven/its/mng3341/maven-
metadata.xml.sha1
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/maven/its/mng3341/test-artifact/
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/maven/its/mng3341/test-artifact/
1.0-SNAPSHOT/
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/maven/its/mng3341/test-artifact/
1.0-SNAPSHOT/maven-metadata.xml   (with props)
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/maven/its/mng3341/test-artifact/
1.0-SNAPSHOT/maven-metadata.xml.md5
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/maven/its/mng3341/test-artifact/
1.0-SNAPSHOT/maven-metadata.xml.sha1
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/maven/its/mng3341/test-artifact/
1.0-SNAPSHOT/test-artifact-1.0-20080306.011328-1.jar   (with props)
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
deployment-repository/org/apache/maven/its/mng3341/test-artifact/
1.0-SNAPSHOT/test-artifact-1.0-20080306.011328-1.jar.md5
  maven/core-integration-testing/trunk/core-integration-tests/src/
test/resources/mn

Re: [pre vote take 3] 2.0.9-RC3

[Raphaël Piéroni]

+1 for the new process.
not yet tested the bundle.

Raphaël

2008/3/26, Brian E. Fox <[EMAIL PROTECTED]>:
> We fixed the regressions identified last week with the plugin tools and
>  reporting impl. The new 2.0.9 is staged at
>
>
>
>  http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
>  che-maven/2.0.9-RC3/
>
>
>
>  You'll notice that this one has an RC qualifier attached to it. Since
>  what I've actually been staging hasn't been for an official vote, it
>  makes more sense to have actual deterministic numbers on them instead of
>  continuously rolling back and forth between .10 and .9.
>
>
>
>  The other significant reason it has a qualifier is that I want to
>  solicit feedback from the users list without potentially getting
>  multiple versions out there called 2.0.9. My new mantra for the maven
>  release is "no more regressions". To that end, what I intend to do is
>  let the RC sit here for a day. If no one turns up anything new (it
>  should be good since this is really attempt #3), then I'll email the
>  user list to solicit feedback. Naturally we'll probably get a slew of
>  "can you fix xyz" but the only thing that we will consider at this point
>  would be a regression from 2.0.8 to the current RC. If something is
>  identified then we should consider fixing it and re-releasing RC4. I
>  think that having the users more involved in testing the RCs is the only
>  way to really identify and eliminate regressions. If someone identifies
>  a regression after the fact and didn't speak up or try it, well that's
>  unfortunate but it'll have to wait.
>
>
>
>  The RC can sit with the users for 3 days. If nothing turns up, then I'll
>  restage with a final release tag and we can do a formal vote. Assuming
>  this is all successful, then I'll document a more formal Core release
>  procedure that we can follow going forward.
>
>
>
>  Here's the list of issues fixed in the latest RC:
>
>
>
>  Release Notes - Maven 2 - Version 2.0.9
>
>
>
>
>
>  ** Bug
>
> * [MNG-1412] - dependency sorting in classpath
>
> * [MNG-1914] - Wrong url in error message when using a mirror
>
> * [MNG-2123] - NullPointerException when a dependency uses version
>  range and another uses an actual version incompatible with that range
>
> * [MNG-2145] - Plugins' dependencies are not always checked
>
> * [MNG-2178] - incorrect M2_HOME guess in mvn.bat
>
> * [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
>  profiles section is missing or empty
>
> * [MNG-2339] - ${project.*} are interpreted in the wrong place
>
> * [MNG-2744] - checksum comparison should be case-insensitive
>
> * [MNG-2809] - Can't activate a profile by checking for the presence
>  of a file in ${user.home}
>
> * [MNG-2848] - Environment variables in profile activation not
>  working
>
> * [MNG-2861] - NullPointerException in DefaultArtifactCollector for
>  relocated resolvedArtifacts with different version ranges and available
>  versions.
>
> * [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if
>  there's no mojo in pom.xml
>
> * [MNG-2928] - Null pointer exeception when introducing version
>  range [major.minor.build-SNAPSHOT,)
>
> * [MNG-2972] - Ignores version of plugin dependency specified in my
>  pom
>
> * [MNG-3086] - NullPointerException in
>  ResolutionNode.getTrail(ResolutionNode.java:136)
>
> * [MNG-3099] - Profiles ignored when working with non-projects (such
>  as archetype:create)
>
> * [MNG-3111] - Classpath order incorrect
>
> * [MNG-3156] - NullPointerException with mvn dependency:sources
>
> * [MNG-3221] - Infinite loop in DefaultLifecycleExecutor
>
> * [MNG-3259] - Regression: Maven drops dependencies in multi-module
>  build
>
> * [MNG-3286] - execution.inherited field is ignored
>
> * [MNG-3288] - Invalid systemPath allows build to continue--failing
>  in later phase.
>
> * [MNG-3296] - mvn.bat looses error code on windows NT type
>  platforms
>
> * [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set
>
> * [MNG-3316] - Barfs at attribues named .*encoding
>
> * [MNG-3354] - mvn.bat incorrectly detects OS on Windows NT or XP
>  with Novell login
>
> * [MNG-3355] - CLONE -${pom.build.sourceDirectory} and
>  ${pom.build.testSourceDirectory} no longer recognized
>
> * [MNG-3365] - Remove trailing-backslashes from M2_HOME in mvn.bat
>
> * [MNG-3394] - Plugin versions inherited via 
>  cannot be overriden by . section of sub modules
>
> * [MNG-3396] - Managed versions dont affect over constrained ranges
>
> * [MNG-3400] - MavenProject is not extensible
>
> * [MNG-3405] - "Checking for updates from repository" logging should
>  not display if WagonManager is offline
>
> * [MNG-3410] - Managed versions in plugins are not considered when
>  using them
>
> * [MNG-3415] - Transfer errors cause junk metadata in the local repo
>
> * [MNG-3426] - regression

RE: Building source jar using shade plugin

[WALTERS, CRAIG P [AG/1000]]

That worked great. Thanks Dan.

-Original Message-
From: Daniel Kulp [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2008 3:02 PM
To: dev@maven.apache.org
Cc: Jason van Zyl
Subject: Re: Building source jar using shade plugin

On Wednesday 26 March 2008, Jason van Zyl wrote:
> Doesn't support it currently.

Yes it does.

Add to your configuration:
true

Dan



>
> On 26-Mar-08, at 12:24 PM, WALTERS, CRAIG P [AG/1000] wrote:
> > I am using shade to build a single jar out of 3 jars in a
> > multi-module project.  I have it building the Uber-jar of class file
> > but I can't figure out how to have it also build the Uber-jar of
> > source.  How can I
> > get it to build the uber-source-jar
> >
> > 
> >- This e-mail message may contain
> > privileged and/or confidential information, and is intended to be
> > received only by persons entitled to receive such information. If
> > you have received this e-mail in error, please notify the sender
> > immediately. Please delete it and all attachments from any servers,
> > hard drives or any other media. Other use of this e-mail by you is
> > strictly prohibited.
> >
> >
> > All e-mails and attachments sent and received are subject to
> > monitoring, reading and archival by Monsanto, including its
> > subsidiaries. The recipient of this e-mail is solely responsible for
> > checking for the presence of "Viruses" or other "Malware". Monsanto,
> > along with its subsidiaries, accepts no liability for any damage
> > caused by any such code transmitted by or accompanying this e-mail
> > or any attachment.
> > 
> >-
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> --
>
> You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
>
> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



-- 
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
This e-mail message may contain privileged and/or confidential information, and 
is intended to be received only by persons entitled to receive such 
information. If you have received this e-mail in error, please notify the 
sender immediately. Please delete it and all attachments from any servers, hard 
drives or any other media. Other use of this e-mail by you is strictly 
prohibited.


All e-mails and attachments sent and received are subject to monitoring, 
reading and archival by Monsanto, including its subsidiaries. The recipient of 
this e-mail is solely responsible for checking for the presence of "Viruses" or 
other "Malware". Monsanto, along with its subsidiaries, accepts no liability 
for any damage caused by any such code transmitted by or accompanying this 
e-mail or any attachment.
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Building source jar using shade plugin

[Daniel Kulp]

On Wednesday 26 March 2008, Daniel Kulp wrote:
> On Wednesday 26 March 2008, Jason van Zyl wrote:
> > Doesn't support it currently.
>
> Yes it does.
>
> Add to your configuration:
> true

One thing I should add though is if the sources jars aren't available, it 
currently barfs.   For CXF, we have that set as:

${createSourcesJar}

With the default property setting createSourcesJar to false.   However, 
our "deploy" and release profiles set that to true since the sources 
jars should be built as part of those profiles.

Dan



> Dan
>
> > On 26-Mar-08, at 12:24 PM, WALTERS, CRAIG P [AG/1000] wrote:
> > > I am using shade to build a single jar out of 3 jars in a
> > > multi-module project.  I have it building the Uber-jar of class
> > > file but I can't figure out how to have it also build the Uber-jar
> > > of source.  How can I
> > > get it to build the uber-source-jar
> > >
> > > --
> > >-- - This e-mail message may
> > > contain privileged and/or confidential information, and is
> > > intended to be received only by persons entitled to receive such
> > > information. If you have received this e-mail in error, please
> > > notify the sender immediately. Please delete it and all
> > > attachments from any servers, hard drives or any other media.
> > > Other use of this e-mail by you is strictly prohibited.
> > >
> > >
> > > All e-mails and attachments sent and received are subject to
> > > monitoring, reading and archival by Monsanto, including its
> > > subsidiaries. The recipient of this e-mail is solely responsible
> > > for checking for the presence of "Viruses" or other "Malware".
> > > Monsanto, along with its subsidiaries, accepts no liability for
> > > any damage caused by any such code transmitted by or accompanying
> > > this e-mail or any attachment.
> > > --
> > >-- -
> >
> > Thanks,
> >
> > Jason
> >
> > --
> > Jason van Zyl
> > Founder,  Apache Maven
> > jason at sonatype dot com
> > --
> >
> > You are never dedicated to something you have complete confidence
> > in. No one is fanatically shouting that the sun is going to rise
> > tomorrow. They know it is going to rise tomorrow. When people are
> > fanatically dedicated to political or religious faiths or any other
> > kind of dogmas or goals, it's always because these dogmas or
> > goals are in doubt.
> >
> > -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
> >
> >
> >
> >
> > 
> >- To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]



-- 
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Building source jar using shade plugin

[Daniel Kulp]

On Wednesday 26 March 2008, Jason van Zyl wrote:
> Doesn't support it currently.

Yes it does.

Add to your configuration:
true

Dan



>
> On 26-Mar-08, at 12:24 PM, WALTERS, CRAIG P [AG/1000] wrote:
> > I am using shade to build a single jar out of 3 jars in a
> > multi-module project.  I have it building the Uber-jar of class file
> > but I can't figure out how to have it also build the Uber-jar of
> > source.  How can I
> > get it to build the uber-source-jar
> >
> > 
> >- This e-mail message may contain
> > privileged and/or confidential information, and is intended to be
> > received only by persons entitled to receive such information. If
> > you have received this e-mail in error, please notify the sender
> > immediately. Please delete it and all attachments from any servers,
> > hard drives or any other media. Other use of this e-mail by you is
> > strictly prohibited.
> >
> >
> > All e-mails and attachments sent and received are subject to
> > monitoring, reading and archival by Monsanto, including its
> > subsidiaries. The recipient of this e-mail is solely responsible for
> > checking for the presence of "Viruses" or other "Malware". Monsanto,
> > along with its subsidiaries, accepts no liability for any damage
> > caused by any such code transmitted by or accompanying this e-mail
> > or any attachment.
> > 
> >-
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> jason at sonatype dot com
> --
>
> You are never dedicated to something you have complete confidence in.
> No one is fanatically shouting that the sun is going to rise tomorrow.
> They know it is going to rise tomorrow. When people are fanatically
> dedicated to political or religious faiths or any other kind of
> dogmas or goals, it's always because these dogmas or
> goals are in doubt.
>
> -- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
>
>
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]



-- 
J. Daniel Kulp
Principal Engineer, IONA
[EMAIL PROTECTED]
http://www.dankulp.com/blog

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Building source jar using shade plugin

[WALTERS, CRAIG P [AG/1000]]

Is there an alternative?

-Original Message-
From: Jason van Zyl [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2008 2:31 PM
To: Maven Developers List
Subject: Re: Building source jar using shade plugin

Doesn't support it currently.

On 26-Mar-08, at 12:24 PM, WALTERS, CRAIG P [AG/1000] wrote:
> I am using shade to build a single jar out of 3 jars in a multi-module
> project.  I have it building the Uber-jar of class file but I can't
> figure out how to have it also build the Uber-jar of source.  How  
> can I
> get it to build the uber-source-jar
>
>

-
> This e-mail message may contain privileged and/or confidential  
> information, and is intended to be received only by persons entitled  
> to receive such information. If you have received this e-mail in  
> error, please notify the sender immediately. Please delete it and  
> all attachments from any servers, hard drives or any other media.  
> Other use of this e-mail by you is strictly prohibited.
>
>
> All e-mails and attachments sent and received are subject to  
> monitoring, reading and archival by Monsanto, including its  
> subsidiaries. The recipient of this e-mail is solely responsible for  
> checking for the presence of "Viruses" or other "Malware". Monsanto,  
> along with its subsidiaries, accepts no liability for any damage  
> caused by any such code transmitted by or accompanying this e-mail  
> or any attachment.
>

-
>

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.

-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance 




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
This e-mail message may contain privileged and/or confidential information, and 
is intended to be received only by persons entitled to receive such 
information. If you have received this e-mail in error, please notify the 
sender immediately. Please delete it and all attachments from any servers, hard 
drives or any other media. Other use of this e-mail by you is strictly 
prohibited.


All e-mails and attachments sent and received are subject to monitoring, 
reading and archival by Monsanto, including its subsidiaries. The recipient of 
this e-mail is solely responsible for checking for the presence of "Viruses" or 
other "Malware". Monsanto, along with its subsidiaries, accepts no liability 
for any damage caused by any such code transmitted by or accompanying this 
e-mail or any attachment.
-


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[pre vote take 3] 2.0.9-RC3

[Brian E. Fox]

We fixed the regressions identified last week with the plugin tools and
reporting impl. The new 2.0.9 is staged at 

 

http://people.apache.org/~brianf/staging-repository/org/apache/maven/apa
che-maven/2.0.9-RC3/

 

You'll notice that this one has an RC qualifier attached to it. Since
what I've actually been staging hasn't been for an official vote, it
makes more sense to have actual deterministic numbers on them instead of
continuously rolling back and forth between .10 and .9.

 

The other significant reason it has a qualifier is that I want to
solicit feedback from the users list without potentially getting
multiple versions out there called 2.0.9. My new mantra for the maven
release is "no more regressions". To that end, what I intend to do is
let the RC sit here for a day. If no one turns up anything new (it
should be good since this is really attempt #3), then I'll email the
user list to solicit feedback. Naturally we'll probably get a slew of
"can you fix xyz" but the only thing that we will consider at this point
would be a regression from 2.0.8 to the current RC. If something is
identified then we should consider fixing it and re-releasing RC4. I
think that having the users more involved in testing the RCs is the only
way to really identify and eliminate regressions. If someone identifies
a regression after the fact and didn't speak up or try it, well that's
unfortunate but it'll have to wait.

 

The RC can sit with the users for 3 days. If nothing turns up, then I'll
restage with a final release tag and we can do a formal vote. Assuming
this is all successful, then I'll document a more formal Core release
procedure that we can follow going forward.

 

Here's the list of issues fixed in the latest RC:

 

Release Notes - Maven 2 - Version 2.0.9

 

 

** Bug

* [MNG-1412] - dependency sorting in classpath

* [MNG-1914] - Wrong url in error message when using a mirror

* [MNG-2123] - NullPointerException when a dependency uses version
range and another uses an actual version incompatible with that range

* [MNG-2145] - Plugins' dependencies are not always checked

* [MNG-2178] - incorrect M2_HOME guess in mvn.bat

* [MNG-2234] - activeProfile in ~/.m2/settings.xml is ignored when
profiles section is missing or empty

* [MNG-2339] - ${project.*} are interpreted in the wrong place

* [MNG-2744] - checksum comparison should be case-insensitive

* [MNG-2809] - Can't activate a profile by checking for the presence
of a file in ${user.home}

* [MNG-2848] - Environment variables in profile activation not
working

* [MNG-2861] - NullPointerException in DefaultArtifactCollector for
relocated resolvedArtifacts with different version ranges and available
versions.

* [MNG-2925] - NullPointerException in PluginDescriptor.getMojo() if
there's no mojo in pom.xml

* [MNG-2928] - Null pointer exeception when introducing version
range [major.minor.build-SNAPSHOT,)

* [MNG-2972] - Ignores version of plugin dependency specified in my
pom

* [MNG-3086] - NullPointerException in
ResolutionNode.getTrail(ResolutionNode.java:136)

* [MNG-3099] - Profiles ignored when working with non-projects (such
as archetype:create)

* [MNG-3111] - Classpath order incorrect

* [MNG-3156] - NullPointerException with mvn dependency:sources

* [MNG-3221] - Infinite loop in DefaultLifecycleExecutor

* [MNG-3259] - Regression: Maven drops dependencies in multi-module
build

* [MNG-3286] - execution.inherited field is ignored

* [MNG-3288] - Invalid systemPath allows build to continue--failing
in later phase.

* [MNG-3296] - mvn.bat looses error code on windows NT type
platforms

* [MNG-3310] - JAVACMD set incorrectly when JAVA_HOME is not set

* [MNG-3316] - Barfs at attribues named .*encoding

* [MNG-3354] - mvn.bat incorrectly detects OS on Windows NT or XP
with Novell login

* [MNG-3355] - CLONE -${pom.build.sourceDirectory} and
${pom.build.testSourceDirectory} no longer recognized

* [MNG-3365] - Remove trailing-backslashes from M2_HOME in mvn.bat

* [MNG-3394] - Plugin versions inherited via 
cannot be overriden by . section of sub modules

* [MNG-3396] - Managed versions dont affect over constrained ranges

* [MNG-3400] - MavenProject is not extensible

* [MNG-3405] - "Checking for updates from repository" logging should
not display if WagonManager is offline

* [MNG-3410] - Managed versions in plugins are not considered when
using them

* [MNG-3415] - Transfer errors cause junk metadata in the local repo

* [MNG-3426] - regression :  in plugin configuration
doesn't override plugin classpath

* [MNG-3430] - Toolchain doesn't match Toolchain extensions

* [MNG-3431] - Pom Extensions not supported for Toolchains

* [MNG-3439] - incorrect child dependency selected when parent is
not selected

* [MNG-3441] - Maven should always retrieve metadata to be updated
from the deployment r

Re: Building source jar using shade plugin

[Jason van Zyl]

Doesn't support it currently.

On 26-Mar-08, at 12:24 PM, WALTERS, CRAIG P [AG/1000] wrote:

I am using shade to build a single jar out of 3 jars in a multi-module
project.  I have it building the Uber-jar of class file but I can't
figure out how to have it also build the Uber-jar of source.  How  
can I

get it to build the uber-source-jar

-
This e-mail message may contain privileged and/or confidential  
information, and is intended to be received only by persons entitled  
to receive such information. If you have received this e-mail in  
error, please notify the sender immediately. Please delete it and  
all attachments from any servers, hard drives or any other media.  
Other use of this e-mail by you is strictly prohibited.



All e-mails and attachments sent and received are subject to  
monitoring, reading and archival by Monsanto, including its  
subsidiaries. The recipient of this e-mail is solely responsible for  
checking for the presence of "Viruses" or other "Malware". Monsanto,  
along with its subsidiaries, accepts no liability for any damage  
caused by any such code transmitted by or accompanying this e-mail  
or any attachment.

-



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.

-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance 





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Building source jar using shade plugin

[WALTERS, CRAIG P [AG/1000]]

I am using shade to build a single jar out of 3 jars in a multi-module
project.  I have it building the Uber-jar of class file but I can't
figure out how to have it also build the Uber-jar of source.  How can I
get it to build the uber-source-jar

-
This e-mail message may contain privileged and/or confidential information, and 
is intended to be received only by persons entitled to receive such 
information. If you have received this e-mail in error, please notify the 
sender immediately. Please delete it and all attachments from any servers, hard 
drives or any other media. Other use of this e-mail by you is strictly 
prohibited.


All e-mails and attachments sent and received are subject to monitoring, 
reading and archival by Monsanto, including its subsidiaries. The recipient of 
this e-mail is solely responsible for checking for the presence of "Viruses" or 
other "Malware". Monsanto, along with its subsidiaries, accepts no liability 
for any damage caused by any such code transmitted by or accompanying this 
e-mail or any attachment.
-

Re: Hudons @ Sonatype

[Jason van Zyl]

Sorry, I meant Hudson. I don't think Hudons is a word.

On 26-Mar-08, at 10:27 AM, Jason van Zyl wrote:

Hi,

We are officially moving from Resin to Jetty for production over at  
Contegix so we'll be down for a couple hours while they switch over.  
Hudson will be back up in a bit, we are just working with Greg/Jan/ 
Contegix to sort out any issues with Jetty so it won't take long.


Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more  
examples

you look at, the more general your framework will be.

-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

A party which is not afraid of letting culture,
business, and welfare go to ruin completely can
be omnipotent for a while.

-- Jakob Burckhardt 





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Hudons @ Sonatype

[Jason van Zyl]

Hi,

We are officially moving from Resin to Jetty for production over at  
Contegix so we'll be down for a couple hours while they switch over.  
Hudson will be back up in a bit, we are just working with Greg/Jan/ 
Contegix to sort out any issues with Jetty so it won't take long.


Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--

People develop abstractions by generalizing from concrete examples.
Every attempt to determine the correct abstraction on paper without
actually developing a running system is doomed to failure. No one
is that smart. A framework is a resuable design, so you develop it by
looking at the things it is supposed to be a design of. The more  
examples

you look at, the more general your framework will be.

-- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks 





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: svn commit: r639861 - in /maven/plugin-tools/trunk: maven-plugin-plugin/pom.xml pom.xml

[Brian E. Fox]

I started to do that and then realized that plugin-plugin doesn't
inherit from the plugin-tools parent, but the plugins parent instead.

-Original Message-
From: Vincent Siveton [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, March 26, 2008 8:04 AM
To: dev@maven.apache.org
Subject: Re: svn commit: r639861 - in /maven/plugin-tools/trunk:
maven-plugin-plugin/pom.xml pom.xml

Hi Brian,

I guess it would be better to fix parent pom and provide a new release.
It will avoid to duplicate entry poms (see this revision or also
r638164)

Cheers,

Vincent

2008/3/21, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Author: brianf
>  Date: Fri Mar 21 14:34:16 2008
>  New Revision: 639861
>
>  URL: http://svn.apache.org/viewvc?rev=639861&view=rev
>  Log:
>  don't use javadoc 2.3
>
>  Modified:
> maven/plugin-tools/trunk/maven-plugin-plugin/pom.xml
> maven/plugin-tools/trunk/pom.xml
>
>  Modified: maven/plugin-tools/trunk/maven-plugin-plugin/pom.xml
>  URL:
http://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-plugi
n/pom.xml?rev=639861&r1=639860&r2=639861&view=diff
>

==
>  --- maven/plugin-tools/trunk/maven-plugin-plugin/pom.xml (original)
>  +++ maven/plugin-tools/trunk/maven-plugin-plugin/pom.xml Fri Mar 21
14:34:16 2008
>  @@ -188,6 +188,11 @@
>maven-plugin-plugin
>2.3
>  
>  +
>  +  org.apache.maven.plugins
>  +  maven-javadoc-plugin
>  +  2.4
>  +
>
>  
>  

Re: i am facing problem when i using tomcat 6.0 + maven2

[Jason van Zyl]

Please stop using the developer list for user questions. People answer  
when they can, as they can and that's done on the user mailing lists  
which you can find here:


[EMAIL PROTECTED]

On 26-Mar-08, at 2:53 AM, <[EMAIL PROTECTED]> <[EMAIL PROTECTED] 
> wrote:



I am very sorry,

I need help urgently I have problem with using tomcat 6.0.14 with  
maven2

+ cargo.
Can u help or give suggestions

Thanks & Regards,

Sridhar Thota,


This message is for the designated recipient only and may contain  
privileged, proprietary, or otherwise private information.  If you  
have received it in error, please notify the sender immediately and  
delete the original.  Any other use of the email by you is prohibited.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
jason at sonatype dot com
--





-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r634131 - in /maven/core-integration-testing/trunk/core-integration-tests/src/test: java/org/apache/maven/integrationtests/ resources/mng-3341-metadataUpdatedFromDeploymentRepository/

[Vincent Siveton]

Hi,

I am happy to work on this. I propose to rename IT resources like the following:
mng-3341-metadataUpdatedFromDeploymentRepository -> mng-3341
And adding a README or a pom description inside the dir.

Cheers,

Vincent

2008/3/11, Brett Porter <[EMAIL PROTECTED]>:
> Yeah, I noticed this on some others too. I'm going to have a go at
>  getting this all in line now.
>
>  - Brett
>
>
>  On 12/03/2008, at 8:26 AM, Vincent Siveton wrote:
>
>  > Hi Brett,
>  >
>  > Could you reduce the dir names for
>  > mng-3341-metadataUpdatedFromDeploymentRepository?
>  >
>  > I am unable to do an update on windows ...
>  >
>  > Thanks.
>  >
>  > Vincent
>  >
>  > 2008/3/5, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
>  >> Author: brett
>  >> Date: Wed Mar  5 18:35:59 2008
>  >> New Revision: 634131
>  >>
>  >> URL: http://svn.apache.org/viewvc?rev=634131&view=rev
>  >> Log:
>  >> [MNG-3341] only look in the original deployment repository for
>  >> metadata to update
>  >>
>  >> Added:
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/java/org/apache/maven/integrationtests/
>  >> MavenITmng3341MetadataUpdatedFromDeploymentRepositoryTest.java
>  >>  - copied, changed from r633736, maven/core-integration-testing/
>  >> trunk/core-integration-tests/src/test/java/org/apache/maven/
>  >> integrationtests/MavenITmng2234ActiveProfilesFromSettingsTest.java
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/apache/
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/apache/maven/
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/apache/maven/its/
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/apache/maven/its/mng3341/
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/apache/maven/its/mng3341/maven-
>  >> metadata.xml   (with props)
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/apache/maven/its/mng3341/maven-
>  >> metadata.xml.md5
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/apache/maven/its/mng3341/maven-
>  >> metadata.xml.sha1
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/apache/maven/its/mng3341/test-artifact/
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/apache/maven/its/mng3341/test-artifact/
>  >> 1.0-SNAPSHOT/
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/apache/maven/its/mng3341/test-artifact/
>  >> 1.0-SNAPSHOT/maven-metadata.xml   (with props)
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/apache/maven/its/mng3341/test-artifact/
>  >> 1.0-SNAPSHOT/maven-metadata.xml.md5
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/apache/maven/its/mng3341/test-artifact/
>  >> 1.0-SNAPSHOT/maven-metadata.xml.sha1
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng-3341-metadataUpdatedFromDeploymentRepository/
>  >> deployment-repository/org/apache/maven/its/mng3341/test-artifact/
>  >> 1.0-SNAPSHOT/test-artifact-1.0-20080306.011328-1.jar   (with props)
>  >>maven/core-integration-testing/trunk/core-integration-tests/src/
>  >> test/resources/mng

Re: svn commit: r639861 - in /maven/plugin-tools/trunk: maven-plugin-plugin/pom.xml pom.xml

[Vincent Siveton]

Hi Brian,

I guess it would be better to fix parent pom and provide a new release.
It will avoid to duplicate entry poms (see this revision or also r638164)

Cheers,

Vincent

2008/3/21, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Author: brianf
>  Date: Fri Mar 21 14:34:16 2008
>  New Revision: 639861
>
>  URL: http://svn.apache.org/viewvc?rev=639861&view=rev
>  Log:
>  don't use javadoc 2.3
>
>  Modified:
> maven/plugin-tools/trunk/maven-plugin-plugin/pom.xml
> maven/plugin-tools/trunk/pom.xml
>
>  Modified: maven/plugin-tools/trunk/maven-plugin-plugin/pom.xml
>  URL: 
> http://svn.apache.org/viewvc/maven/plugin-tools/trunk/maven-plugin-plugin/pom.xml?rev=639861&r1=639860&r2=639861&view=diff
>  
> ==
>  --- maven/plugin-tools/trunk/maven-plugin-plugin/pom.xml (original)
>  +++ maven/plugin-tools/trunk/maven-plugin-plugin/pom.xml Fri Mar 21 14:34:16 
> 2008
>  @@ -188,6 +188,11 @@
>maven-plugin-plugin
>2.3
>  
>  +
>  +  org.apache.maven.plugins
>  +  maven-javadoc-plugin
>  +  2.4
>  +
>
>  
>  

Re: svn commit: r640098 - in /maven/shared/trunk/maven-doxia-tools/src/site: ./ apt/ apt/index.apt site.xml

[Vincent Siveton]

Thanks for this Dennis.

Vincent

2008/3/22, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Author: dennisl
>  Date: Sat Mar 22 15:22:05 2008
>  New Revision: 640098
>
>  URL: http://svn.apache.org/viewvc?rev=640098&view=rev
>  Log:
>  o Add a minimal site.
>
>  Added:
> maven/shared/trunk/maven-doxia-tools/src/site/
> maven/shared/trunk/maven-doxia-tools/src/site/apt/
> maven/shared/trunk/maven-doxia-tools/src/site/apt/index.apt   (with props)
> maven/shared/trunk/maven-doxia-tools/src/site/site.xml   (with props)
>
>  Added: maven/shared/trunk/maven-doxia-tools/src/site/apt/index.apt
>  URL: 
> http://svn.apache.org/viewvc/maven/shared/trunk/maven-doxia-tools/src/site/apt/index.apt?rev=640098&view=auto
>  
> ==
>  --- maven/shared/trunk/maven-doxia-tools/src/site/apt/index.apt (added)
>  +++ maven/shared/trunk/maven-doxia-tools/src/site/apt/index.apt Sat Mar 22 
> 15:22:05 2008
>  @@ -0,0 +1,71 @@
>  + --
>  + Introduction
>  + --
>  + Dennis Lundberg
>  + --
>  + 2008-03-22
>  + --
>  +
>  + ~~ Licensed to the Apache Software Foundation (ASF) under one
>  + ~~ or more contributor license agreements.  See the NOTICE file
>  + ~~ distributed with this work for additional information
>  + ~~ regarding copyright ownership.  The ASF licenses this file
>  + ~~ to you under the Apache License, Version 2.0 (the
>  + ~~ "License"); you may not use this file except in compliance
>  + ~~ with the License.  You may obtain a copy of the License at
>  + ~~
>  + ~~   http://www.apache.org/licenses/LICENSE-2.0
>  + ~~
>  + ~~ Unless required by applicable law or agreed to in writing,
>  + ~~ software distributed under the License is distributed on an
>  + ~~ "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
>  + ~~ KIND, either express or implied.  See the License for the
>  + ~~ specific language governing permissions and limitations
>  + ~~ under the License.
>  +
>  + ~~ NOTE: For help with the syntax of this file, see:
>  + ~~ http://maven.apache.org/doxia/references/apt-format.html
>  +
>  +
>  +Maven Doxia Tools
>  +
>  +  This shared component has some utilities that are useful when working with
>  +  site generation and report creation. The main entry point is the
>  +  {{{apidocs/org/apache/maven/doxia/tools/SiteTool.html}SiteTool}} Plexus
>  +  component.
>  +
>  +
>  +* Using the SiteTool in a Mojo
>  +
>  ++-
>  +...
>  +import org.apache.maven.doxia.tools.SiteTool;
>  +...
>  +
>  +/**
>  + * Your own mojo.
>  + */
>  +public class YourOwnMojo extends AbstractMojo
>  +{
>  +...
>  +
>  +/**
>  + * SiteTool.
>  + *
>  + * @component
>  + */
>  +protected SiteTool siteTool;
>  +
>  +...
>  +
>  +public someMethod()
>  +{
>  +List localesList = siteTool.getAvailableLocales( locales );
>  +String relativePath = siteTool.getRelativePath( "C:/foo/child",
>  +"C:/foo/master" );
>  +...
>  +}
>  +
>  +...
>  +}
>  ++-
>
>  Propchange: maven/shared/trunk/maven-doxia-tools/src/site/apt/index.apt
>  
> --
> svn:eol-style = native
>
>  Added: maven/shared/trunk/maven-doxia-tools/src/site/site.xml
>  URL: 
> http://svn.apache.org/viewvc/maven/shared/trunk/maven-doxia-tools/src/site/site.xml?rev=640098&view=auto
>  
> ==
>  --- maven/shared/trunk/maven-doxia-tools/src/site/site.xml (added)
>  +++ maven/shared/trunk/maven-doxia-tools/src/site/site.xml Sat Mar 22 
> 15:22:05 2008
>  @@ -0,0 +1,29 @@
>  +
>  +
>  +
>  +
>  +
>  +  
>  +
>  +  
>  +
>  +
>  +  
>  +
>
>  Propchange: maven/shared/trunk/maven-doxia-tools/src/site/site.xml
>  
> --
> svn:eol-style = native
>
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

is maven2 and cargo support tomcat 6 ?

[sridhar.thota]

Hi 

 

Maven2 and cargo supports tomcat 6?

 

Can anyone help script for start/stop the tomcat 6 server

 

Thanks & Regards,

 Sridhar Thota

 



This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.

Re: Maven and File Encoding

[Benjamin Bentmann]

What about just unifying the expressions that refer to encoding in 
plugins?


As an intermediate solution until Maven 2.1 provides an extended POM, this 
seems like a good approach.



javadoc-plugin has ${encoding}
compiler-plugin has ${maven.compiler.encoding}
resources-plugin has no expression defined.


My suggestion: ${project.build.sourceEncoding} or similar, i.e. have the 
expression match the yet to introduce new POM element for the encoding. This 
way, plugins using the expression would be forward-compatible with the 
extended POM and automatically use the new POM element once introduced.


We could also consider to add

 
   ISO-8859-1
 

to the super POM for everyone to inherit. This in place, plugin parameters 
could be written like


 /**
  * @parameter expression="${encoding}"
  *default-value="${project.build.sourceEncoding}"
  */
 private String encoding;

i.e. still provide some short expression name for overrides from the cli. Of 
course, this would require the plugin to add a manual check whether the 
default-value expression actually was existent or whether an older Maven 
version is running.



Benjamin 



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r640515 - /maven/shared/branches/maven-reporting-impl-2.0.4.1-dev/pom.xml

[Vincent Siveton]

Hi Brian,

IMHO calling this branch maven-reporting-impl-2.0.4.x sounds better. WDYT?

Cheers,

Vincent

2008/3/24, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Author: brianf
>  Date: Mon Mar 24 11:44:36 2008
>  New Revision: 640515
>
>  URL: http://svn.apache.org/viewvc?rev=640515&view=rev
>  Log:
>  [maven-release-plugin] prepare for next development iteration
>
>  Modified:
> maven/shared/branches/maven-reporting-impl-2.0.4.1-dev/pom.xml
>
>  Modified: maven/shared/branches/maven-reporting-impl-2.0.4.1-dev/pom.xml
>  URL: 
> http://svn.apache.org/viewvc/maven/shared/branches/maven-reporting-impl-2.0.4.1-dev/pom.xml?rev=640515&r1=640514&r2=640515&view=diff
>  
> ==
>  --- maven/shared/branches/maven-reporting-impl-2.0.4.1-dev/pom.xml (original)
>  +++ maven/shared/branches/maven-reporting-impl-2.0.4.1-dev/pom.xml Mon Mar 
> 24 11:44:36 2008
>  @@ -8,7 +8,7 @@
>maven-reporting-impl
>org.apache.maven.reporting
>Maven Reporting Implementation
>  -  2.0.4.1
>  +  2.0.4.2-SNAPSHOT
>
>
>  
>  @@ -55,9 +55,9 @@
>
>
>
>  -
> scm:svn:http://svn.apache.org/repos/asf/maven/shared/tags/maven-reporting-impl-2.0.4.1
>  -
> scm:svn:https://svn.apache.org/repos/asf/maven/shared/tags/maven-reporting-impl-2.0.4.1
>  -
> http://svn.apache.org/viewcvs.cgi/maven/shared/tags/maven-reporting-impl-2.0.4.1
>  +
> scm:svn:http://svn.apache.org/repos/asf/maven/shared/branches/maven-reporting-impl-2.0.4.1-dev
>  +
> scm:svn:https://svn.apache.org/repos/asf/maven/shared/branches/maven-reporting-impl-2.0.4.1-dev
>  +
> http://svn.apache.org/viewcvs.cgi/maven/shared/branches/maven-reporting-impl-2.0.4.1-dev
>
>
>   
>
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: svn commit: r640193 - /maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report.properties

[Vincent Siveton]

Hi Dennis,

"Dependency Management" is now on 2 lines in the nav bar. Is it the
wanted behaviour?

Cheers,

Vincent

2008/3/23, [EMAIL PROTECTED] <[EMAIL PROTECTED]>:
> Author: dennisl
>  Date: Sun Mar 23 05:38:42 2008
>  New Revision: 640193
>
>  URL: http://svn.apache.org/viewvc?rev=640193&view=rev
>  Log:
>  o Add a proper name and description for report.dependencyManagement and 
> report.pluginManagement.
>  o Fix typos.
>
>  Modified:
> 
> maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report.properties
>
>  Modified: 
> maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report.properties
>  URL: 
> http://svn.apache.org/viewvc/maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report.properties?rev=640193&r1=640192&r2=640193&view=diff
>  
> ==
>  --- 
> maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report.properties
>  (original)
>  +++ 
> maven/plugins/trunk/maven-project-info-reports-plugin/src/main/resources/project-info-report.properties
>  Sun Mar 23 05:38:42 2008
>  @@ -144,8 +144,8 @@
>   report.scm.description = This 
> is a link to the online source repository that can be viewed via a web 
> browser.
>   report.scm.devaccess.clearcase.intro   = Only 
> project developers can access the ClearCase tree via this method. Substitute 
> username with the proper value.
>   report.scm.devaccess.cvs.intro = Only 
> project developers can access the CVS tree via this method. Substitute 
> username with the proper value.
>  -report.scm.devaccess.general.intro = Refer 
> to the documentation of the SCM used for more information about developer 
> checked out. The connection url is:
>  -report.scm.devaccess.perforce.intro= Only 
> project developers can access the Perforce tree via this method. Substitute 
> username and password with the proper value.
>  +report.scm.devaccess.general.intro = Refer 
> to the documentation of the SCM used for more information about developer 
> check out. The connection url is:
>  +report.scm.devaccess.perforce.intro= Only 
> project developers can access the Perforce tree via this method. Substitute 
> username and password with the proper values.
>   report.scm.devaccess.starteam.intro= Only 
> project developers can access the Starteam tree via this method. Substitute 
> username with the proper value.
>   report.scm.devaccess.svn.intro1.https  = 
> Everyone can access the Subversion repository via HTTPS, but Committers must 
> checkout the Subversion repository via HTTPS.
>   report.scm.devaccess.svn.intro1.other  = 
> Committers must checkout the Subversion repository.
>  @@ -216,8 +216,8 @@
>   report.transitivedependencies.intro= The 
> following is a list of transitive dependencies for this project. Transitive 
> dependencies are the dependencies of the project dependencies.
>   report.transitivedependencies.nolist   = No 
> transitive dependencies are required for this project.
>   report.transitivedependencies.title= 
> Project Transitive Dependencies
>  -report.dependencyManagement.name   = 
> Dependency Mngt
>  -report.dependencyManagement.description= 
> description
>  +report.dependencyManagement.name   = 
> Dependency Management
>  +report.dependencyManagement.description= This 
> document lists the dependencies that are defined through dependencyManagement.
>   report.dependencyManagement.title  = 
> Project Dependency Management
>   report.dependencyManagement.nolist = There 
> are no dependencies in the DependencyManagement of this project.
>   report.dependencyManagement.column.groupId = GroupId
>  @@ -230,7 +230,7 @@
>   report.dependencyManagement.intro.runtime  = The 
> following is a list of runtime dependencies in the DependencyManagement of 
> this project. These dependencies can be included in the submodules to run the 
> submodule:
>   report.dependencyManagement.intro.system   = The 
> following is a list of system dependencies in the DependencyManagement of 
> this project. These dependencies can be included in the submodules to compile 
> the submodule:
>   report.dependencyManagement.intro.test = The 
> following is a list of test

Re: Maven and File Encoding

[Milos Kleint]

I've encountered this in the IDE integration for netbeans when I want
to allow users to set encoding for the project. Currently I'm setting
configuration for compiler-plugin and resources-plugin but that's
cumbersome.


On Wed, Mar 26, 2008 at 11:37 AM, Benjamin Bentmann
<[EMAIL PROTECTED]> wrote:
> > There is one feature in this patch I don't like: you hardcoded a default
>  > encoding to ISO-8859-1 instead of no default value (which means platform
>  > encoding).
>
>  Indeed, I also suggested using a fixed default value for other plugins:
>  - MCOMPILER-63
>  - MJAVADOC-165
>  - MRESOURCES-57
>
>  I simply chose Latin-1 here to be consistent with the Site Plugin whose
>  inputEncoding/outputEncoding likewise defaults to Latin-1 for quite some
>  time.
>
>
>  > even if a developer wanted to configure platform encoding, he could not!
>
>  Something like
>   ${file.encoding}
>  should still do, wouldn't it?

adding elements to pom.xml would be incompatible change however and
will take a long time to get in production.. What about just unifying
the expressions that refer to encoding in plugins?
javadoc-plugin has ${encoding}
compiler-plugin has ${maven.compiler.encoding}
resources-plugin has no expression defined.

If all places defined a common name, we would be fine, right? you
would just define the right property in the pom..

Regards


Milos

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [RESULT][VOTE] Release apache-jar-resource-bundle version 1.4

[Vincent Siveton]

Daniel,

Could you also send an email to announce@ and users@ like described in [1]?
Same for maven-shade-plugin and maven-remote-resources

Thanks,

Vincent

[1] http://maven.apache.org/developers/release/releasing.html

2008/3/20, Daniel Kulp <[EMAIL PROTECTED]>:
>
>  This vote passes:
>
>  +1 binding: jvanzyl, brianf, olamy, vsiveton
>  +1 non-binding: jdillon, mtalevi, dkulp
>
>  Thanks!
>  Dan
>
>
>
>
>  On Monday 17 March 2008, Daniel Kulp wrote:
>  > To comply with the latest requirements discussed on legal-discuss, we
>  > need a new version of the apache-jar-resource-bundle.
>  >
>  > The only change is really the result of discussions and testing
>  > around: http://jira.codehaus.org/browse/MRRESOURCES-32
>  > Many thanks to David Jencks for leading that up with legal-discuss.
>  >
>  > Staging area:
>  > http://people.apache.org/~dkulp/stage-bundle/
>  >
>  > Tag:
>  > http://svn.apache.org/repos/asf/maven/resources/tags/apache-jar-resour
>  >ce-bundle-1.4/
>  >
>  > Vote open for 72 hours.
>  >
>  > [ ] +1
>  > [ ] +0
>  > [ ] -1
>
>
>
>  --
>  J. Daniel Kulp
>  Principal Engineer, IONA
>  [EMAIL PROTECTED]
>  http://www.dankulp.com/blog
>
>  -
>  To unsubscribe, e-mail: [EMAIL PROTECTED]
>  For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Maven and File Encoding

[Benjamin Bentmann]

There is one feature in this patch I don't like: you hardcoded a default
encoding to ISO-8859-1 instead of no default value (which means platform
encoding).


Indeed, I also suggested using a fixed default value for other plugins:
- MCOMPILER-63
- MJAVADOC-165
- MRESOURCES-57

I simply chose Latin-1 here to be consistent with the Site Plugin whose
inputEncoding/outputEncoding likewise defaults to Latin-1 for quite some
time.


even if a developer wanted to configure platform encoding, he could not!


Something like
 ${file.encoding}
should still do, wouldn't it?


Platform encoding is here to give most developers freedom to ignore
encoding notions. And most of the time it works well.
Every native tool use platform encoding by default, so do javac, javadoc,
ant,...


You basically describe the status quo for the encoding handling. Now I
believe that some improvements simply require to break with existing
standards to get away from questionable decisions made in the past. For
instance, Maven 2.0.8 and Surefire 2.3.1 introduced deterministic/correct
class path ordering. This caused some people's builds to fail but
nevertheless I believe this change was the only way to go.

Considering the following circumstances
a) Java has an international audience and
b) developer communities are joined from different countries
I believe that to "ignore encoding notions" is an anti-pattern that should
be banned, not supported. Also, I guess that it's partly this ignorance that
caused and still causes all the pain with proper encoding support in Maven:
If developers would have been required to explicitly specify file encodings
for tools like javac or classes like FileWriter/FileReader, I believe that
would have made them sensible to the topic and could have prevented some of
the design/implementation flaws we see right now.

Personally, I'm a fan of these Maven philosophies:
- ensure builds are reproducible
- prefer convention over configuration
If I apply those to the encoding issue as well (as a matter of consistency),
the conclusion is to have Maven provide a fixed default value for the
encoding.


Having a default encoding is not consistent, and people not using
ISO-8859-1 as their platform encoding won't understand the failure (or
understand this is a complicated encoding problem caused by a bad tool).


Also note, that Maven already chose to be inconsistent with native tools
regarding compiler source/target settings. The native javac defaults these
options according to its own JVM while Maven uses fixed default values.
Those defaults caused compilation failures for my builds and made me spend
some minutes to fix the POM. However, I wouldn't blaim Maven here for being
inconsistent, I'm happy it taught me to get my build platform-independent.


To help developers discover that relying on platform encoding is not a
good choice, I think there are better ways than stopping the "magic" of
it:


I feel this is similar to the auto-update "feature" for Maven plugins: I'm
not sure but wasn't the consensus about this to disable auto-update by
requiring the existence of  elements for plugins in the POM für
Maven 2.1? This would also mean a stop of "magic" though in a
smoother/expected way since the POM version would change and as such has all
right to define different validation semantics.


- I just changed resources plugin with MRESOURCES-62 to be more explicit:
> [INFO] [resources:resources]
> [INFO] Using platform encoding (UTF-16 actually) to copy filtered
> resources.


Side note: I would prefer to output the last log message on level "WARNING".
An INFO message is ordinary output noise, nobody will care about that,
leaving the POM as bad as is.


- perhaps Maven itself should show the good habits: define a property in
the parent pom and take care of properly declaring encoding for plugins


I agree here, Maven should definitively have a central property in the POM
to control encoding for an entire build. See also MNG-2216.


Benjamin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: i am facing problem when i using tomcat 6.0 + maven2

[sridhar.thota]

I am very sorry,

I need help urgently I have problem with using tomcat 6.0.14 with maven2
+ cargo.
Can u help or give suggestions 

Thanks & Regards,

Sridhar Thota,


This message is for the designated recipient only and may contain privileged, 
proprietary, or otherwise private information.  If you have received it in 
error, please notify the sender immediately and delete the original.  Any other 
use of the email by you is prohibited.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Please Comment: Maven 2.1 Plugin and Extension Loading Documentation

[Milos Kleint]

sorry for late review, but it looks generally ok to me.

Milos

On Wed, Mar 19, 2008 at 10:41 PM, John Casey <[EMAIL PROTECTED]> wrote:
> Hi everyone,
>
>  As I think I promised last week, I've written up some documentation
>  for the plugin- and extension-loading refactor I did in trunk last
>  fall. It's here:
>
>  http://docs.codehaus.org/display/MAVEN/Maven+2.1+Plugin+and+Extension
>  +Loading+Design
>
>  I'd really appreciate if people could take a few minutes and read
>  through that, and give me your feedback.
>
>  Thanks,
>
>  -john
>
>  ---
>  John Casey
>  Committer and PMC Member, Apache Maven
>  mail: jdcasey at commonjava dot org
>  blog: http://www.ejlife.net/blogs/john
>  rss: http://feeds.feedburner.com/ejlife/john
>
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]