Re: [VOTE] Release Maven-SCM 1.0-rc1

[John Casey]

that works for me.

On 4/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:


I'd say that if in 1/2 weeks nobody finds critical bugs it should be
released final. Non critical bugs can be postponed to 1.0.1

On 4/13/07, John Casey <[EMAIL PROTECTED]> wrote:
> +1, though I'm a little curious whether it would be better to simply try
to
> release a 1.0. If this is good enough for a release candidate, and
you've
> staged it where people can try it out, then this candidate could just be
> pushed out as a final release if nobody reports a problem...
>
> How long of a "soak" period do you feel would be appropriate for this
> release candidate, before we can be sure it's ready to be -final?
>
> -john
>
>
> On 4/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> > +1
> >
> > On 4/13/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > I'd like to release Maven SCM 1.0-rc1
> > > This version fix few bugs, add a new provider (mercurial) and few
> commands.
> > >
> > > Road Map:
> > >
>
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&styleName=Html&version=13066
> > >
> > > Site:
> > > http://people.apache.org/~evenisse/stage/site/
> > >
> > > Staging repo:
> > > http://people.apache.org/~evenisse/stage/repo/
> > >
> > > Tag:
> > >
> http://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.0-rc1/
> > >
> > > So, let's try 72h +1/+0/-1. Please cast your votes!
> > >
> > > Here my +1
> > >
> > > Emmanuel
> > >
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >  -- The Princess Bride
> >
>
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

Re: [VOTE] Release Maven-SCM 1.0-rc1

[Carlos Sanchez]

I'd say that if in 1/2 weeks nobody finds critical bugs it should be
released final. Non critical bugs can be postponed to 1.0.1

On 4/13/07, John Casey <[EMAIL PROTECTED]> wrote:

+1, though I'm a little curious whether it would be better to simply try to
release a 1.0. If this is good enough for a release candidate, and you've
staged it where people can try it out, then this candidate could just be
pushed out as a final release if nobody reports a problem...

How long of a "soak" period do you feel would be appropriate for this
release candidate, before we can be sure it's ready to be -final?

-john


On 4/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> +1
>
> On 4/13/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I'd like to release Maven SCM 1.0-rc1
> > This version fix few bugs, add a new provider (mercurial) and few
commands.
> >
> > Road Map:
> >
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&styleName=Html&version=13066
> >
> > Site:
> > http://people.apache.org/~evenisse/stage/site/
> >
> > Staging repo:
> > http://people.apache.org/~evenisse/stage/repo/
> >
> > Tag:
> >
http://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.0-rc1/
> >
> > So, let's try 72h +1/+0/-1. Please cast your votes!
> >
> > Here my +1
> >
> > Emmanuel
> >
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>  -- The Princess Bride
>





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

Re: [vote] release maven-release-1 parent and maven-release-manager-1.0-alpha-1

[John Casey]

+1

On 4/13/07, Vincent Siveton <[EMAIL PROTECTED]> wrote:


+1

Vincent


2007/4/13, Arnaud HERITIER <[EMAIL PROTECTED]>:
> +1
>
> Arnaud
>
> On 13/04/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
> >
> > +1
> >
> > Emmanuel
> >
> > Jesse McConnell a écrit :
> > > With maven-scm having its latest release underway, the final
linchpin
> > > in getting alpha releases of continuum up and running is the
> > > maven-release and maven-release-manager.
> > >
> > > So I am calling a vote to get the maven-release parent pom released
> > > and the maven-release-manager which the continuum-release module
makes
> > > use of as well as the maven-release-plugin which is _not_ under the
> > > purview of this vote.
> > >
> > > In Staging Repo:
> > > http://people.apache.org/~jmcconnell/org/apache/maven/release
> > >
> > > Tags:
> > > http://svn.apache.org/repos/asf/maven/release/tags/
> > >
> > > Anyway, lets try this and see how it goes:
> > >
> > > 72 hrs +1/0/-1.  Cast away! :)
> > >
> > > jesse
> > >
> > > +1 from me...
> > >
> >
> >
> > -
> > 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: [vote] release maven-release-1 parent and maven-release-manager-1.0-alpha-1

[Vincent Siveton]

+1

Vincent


2007/4/13, Arnaud HERITIER <[EMAIL PROTECTED]>:

+1

Arnaud

On 13/04/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
>
> +1
>
> Emmanuel
>
> Jesse McConnell a écrit :
> > With maven-scm having its latest release underway, the final linchpin
> > in getting alpha releases of continuum up and running is the
> > maven-release and maven-release-manager.
> >
> > So I am calling a vote to get the maven-release parent pom released
> > and the maven-release-manager which the continuum-release module makes
> > use of as well as the maven-release-plugin which is _not_ under the
> > purview of this vote.
> >
> > In Staging Repo:
> > http://people.apache.org/~jmcconnell/org/apache/maven/release
> >
> > Tags:
> > http://svn.apache.org/repos/asf/maven/release/tags/
> >
> > Anyway, lets try this and see how it goes:
> >
> > 72 hrs +1/0/-1.  Cast away! :)
> >
> > jesse
> >
> > +1 from me...
> >
>
>
> -
> 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: [VOTE] Release maven-plugin-testing-harness

[Vincent Siveton]

+1

Vincent


2007/4/13, Brian E. Fox <[EMAIL PROTECTED]>:

+1

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Friday, April 13, 2007 5:13 PM
To: Maven Developers List
Subject: Re: [VOTE] Release maven-plugin-testing-harness

anyone?

On 4/10/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> It adds some stub method implementations from previous releases
>
> Right now it's 1.0-beta-2 but has been pretty stable during last year,
> so i'd suggest releasing 1.0 and whatever is added in the future go to
> 1.1, 1.2, ...
>
>
https://svn.apache.org/repos/asf/maven/shared/trunk/maven-plugin-testing
-harness
> 527389
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>  -- The Princess Bride
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

-
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]




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

Re: [VOTE] Release maven-dependency-tree

[Vincent Siveton]

+1

Vincent

2007/4/13, Brian E. Fox <[EMAIL PROTECTED]>:

+1

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Friday, April 13, 2007 5:12 PM
To: Maven Developers List
Subject: Re: [VOTE] Release maven-dependency-tree

anyone?

On 4/10/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> This release adds iterator methods that simplify the tree navigation
>
> Right now is set to 1.0-alpha-3 but has been stable for months so I'd
> go for 1.0-beta-1 or 1.0
>
>
https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tre
e 527390
>
> Note that it depends on the release of the
maven-plugin-testing-harness
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>  -- The Princess Bride
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

-
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]




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

Re: [VOTE] maven-enforcer-plugin:1.0-alpha-2

[Vincent Siveton]

my late +1

Vincent

2007/4/13, Brian E. Fox <[EMAIL PROTECTED]>:

Results:
Binding: +4 (Brian,Luke,Stephane,Arnaud)
Nonbinding: + (Jerome)

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 10, 2007 3:40 PM
To: Maven Developers List
Subject: [VOTE] maven-enforcer-plugin:1.0-alpha-2

This release fixes just one critical issue:

Release Notes - Maven 2.x Enforcer Plugin - Version 1.0-alpha-2

** Bug
* [MENFORCER-1] - plugin fails on jdk < 1.5

The deployments are staged here:

http://people.apache.org/~brianf/staging-repository


Vote is open for 72hrs.

+1




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

Re: [VOTE] maven-remote-resources-plugin 1.0-alpha-5

[Vincent Siveton]

+1

Vincent

2007/4/12, Daniel Kulp <[EMAIL PROTECTED]>:


I'd like to release version 1.0-alpha-5 of the
maven-remote-resources-plugin.   This resolves one critical bug, but
also adds some new features to make it a bit more usable.


Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0-alpha-5

** Bug
* [MRRESOURCES-18] - Error when no 'inceptionYear' is specified in
POM

** Improvement
* [MRRESOURCES-19] - Bundle mojo only looks for txt and vm files
* [MRRESOURCES-20] - Support for binary resources
* [MRRESOURCES-21] - Supplement the data model used by Velocity


Staging area:
http://people.apache.org/~dkulp/stage_remoteresources/

Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.0-alpha-5/

--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[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: [VOTE] Release maven-stylus-skin 1.0.1

[Vincent Siveton]

+1

Vincent

2007/4/11, Dennis Lundberg <[EMAIL PROTECTED]>:

Hi,

I'd like to release maven-stylus-skin 1.0.1. The only existing issue for
this skin has been fixed. The fix is needed by the upcoming version of
Doxia.

Release Notes:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11430&styleName=Html&version=13133

Tag:
http://svn.apache.org/repos/asf/maven/skins/tags/maven-stylus-skin-1.0.1/

Staged at:
http://people.apache.org/~dennisl/staging-repository-stylus-skin/

The vote will be open for 72 hours.


Here is my +1

--
Dennis Lundberg

-
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: [VOTE] Release Maven-SCM 1.0-rc1

[Ryan Daum]

+1 :-)

On 4/13/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:


+1

Arnaud

On 13/04/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> I'd like to release Maven SCM 1.0-rc1
> This version fix few bugs, add a new provider (mercurial) and few
> commands.
>
> Road Map:
>
> 
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&styleName=Html&version=13066
>
> Site:
> http://people.apache.org/~evenisse/stage/site/
> 
>
> Staging repo:
> 
http://people.apache.org/~evenisse/stage/repo/
>
> Tag:
> http://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.0-rc1/
>
> So, let's try 72h +1/+0/-1. Please cast your votes!
>
> Here my +1
>
> Emmanuel
>
>




--
Ryan Daum
[EMAIL PROTECTED]
Senior Developer, Toronto
647.724.5232 x 2073

RE: [VOTE] Release maven-plugin-testing-harness

[Brian E. Fox]

+1

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Friday, April 13, 2007 5:13 PM
To: Maven Developers List
Subject: Re: [VOTE] Release maven-plugin-testing-harness

anyone?

On 4/10/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> It adds some stub method implementations from previous releases
>
> Right now it's 1.0-beta-2 but has been pretty stable during last year,
> so i'd suggest releasing 1.0 and whatever is added in the future go to
> 1.1, 1.2, ...
>
>
https://svn.apache.org/repos/asf/maven/shared/trunk/maven-plugin-testing
-harness
> 527389
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>  -- The Princess Bride
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

-
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: [VOTE] Release maven-dependency-tree

[Brian E. Fox]

+1

-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos
Sanchez
Sent: Friday, April 13, 2007 5:12 PM
To: Maven Developers List
Subject: Re: [VOTE] Release maven-dependency-tree

anyone?

On 4/10/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> This release adds iterator methods that simplify the tree navigation
>
> Right now is set to 1.0-alpha-3 but has been stable for months so I'd
> go for 1.0-beta-1 or 1.0
>
>
https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tre
e 527390
>
> Note that it depends on the release of the
maven-plugin-testing-harness
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>  -- The Princess Bride
>


-- 
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

-
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: [VOTE] Release maven-plugin-testing-harness

[Jesse McConnell]

+1


On 4/13/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:

+1

Arnaud

On 13/04/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
>
> anyone?
>
> On 4/10/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> > It adds some stub method implementations from previous releases
> >
> > Right now it's 1.0-beta-2 but has been pretty stable during last year,
> > so i'd suggest releasing 1.0 and whatever is added in the future go to
> > 1.1, 1.2, ...
> >
> >
> 
https://svn.apache.org/repos/asf/maven/shared/trunk/maven-plugin-testing-harness
> > 527389
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >  -- The Princess Bride
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>  -- The Princess Bride
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>




--
jesse mcconnell
[EMAIL PROTECTED]

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

Re: [VOTE] Release Maven-SCM 1.0-rc1

[Arnaud HERITIER]

+1

Arnaud

On 13/04/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:


Hi,

I'd like to release Maven SCM 1.0-rc1
This version fix few bugs, add a new provider (mercurial) and few
commands.

Road Map:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&styleName=Html&version=13066

Site:
http://people.apache.org/~evenisse/stage/site/

Staging repo:
http://people.apache.org/~evenisse/stage/repo/

Tag:
http://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.0-rc1/

So, let's try 72h +1/+0/-1. Please cast your votes!

Here my +1

Emmanuel

Re: [vote] release maven-release-1 parent and maven-release-manager-1.0-alpha-1

[Arnaud HERITIER]

+1

Arnaud

On 13/04/07, Emmanuel Venisse <[EMAIL PROTECTED]> wrote:


+1

Emmanuel

Jesse McConnell a écrit :
> With maven-scm having its latest release underway, the final linchpin
> in getting alpha releases of continuum up and running is the
> maven-release and maven-release-manager.
>
> So I am calling a vote to get the maven-release parent pom released
> and the maven-release-manager which the continuum-release module makes
> use of as well as the maven-release-plugin which is _not_ under the
> purview of this vote.
>
> In Staging Repo:
> http://people.apache.org/~jmcconnell/org/apache/maven/release
>
> Tags:
> http://svn.apache.org/repos/asf/maven/release/tags/
>
> Anyway, lets try this and see how it goes:
>
> 72 hrs +1/0/-1.  Cast away! :)
>
> jesse
>
> +1 from me...
>


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

Re: [VOTE] Release maven-plugin-testing-harness

[Arnaud HERITIER]

+1

Arnaud

On 13/04/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:


anyone?

On 4/10/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> It adds some stub method implementations from previous releases
>
> Right now it's 1.0-beta-2 but has been pretty stable during last year,
> so i'd suggest releasing 1.0 and whatever is added in the future go to
> 1.1, 1.2, ...
>
>
https://svn.apache.org/repos/asf/maven/shared/trunk/maven-plugin-testing-harness
> 527389
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>  -- The Princess Bride
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

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

Re: [VOTE] Release maven-dependency-tree

[Arnaud HERITIER]

Sorry, didn't see it.

+1

Arnaud

On 13/04/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:


anyone?

On 4/10/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> This release adds iterator methods that simplify the tree navigation
>
> Right now is set to 1.0-alpha-3 but has been stable for months so I'd
> go for 1.0-beta-1 or 1.0
>
>
https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree527390
>
> Note that it depends on the release of the maven-plugin-testing-harness
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>  -- The Princess Bride
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride

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

Re: [VOTE] Release maven-plugin-testing-harness

[Carlos Sanchez]

anyone?

On 4/10/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:

It adds some stub method implementations from previous releases

Right now it's 1.0-beta-2 but has been pretty stable during last year,
so i'd suggest releasing 1.0 and whatever is added in the future go to
1.1, 1.2, ...

https://svn.apache.org/repos/asf/maven/shared/trunk/maven-plugin-testing-harness
527389

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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

Re: [VOTE] Release maven-dependency-tree

[Carlos Sanchez]

anyone?

On 4/10/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:

This release adds iterator methods that simplify the tree navigation

Right now is set to 1.0-alpha-3 but has been stable for months so I'd
go for 1.0-beta-1 or 1.0

https://svn.apache.org/repos/asf/maven/shared/trunk/maven-dependency-tree 527390

Note that it depends on the release of the maven-plugin-testing-harness

--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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

Re: [vote] release maven-release-1 parent and maven-release-manager-1.0-alpha-1

[Emmanuel Venisse]

+1

Emmanuel

Jesse McConnell a écrit :

With maven-scm having its latest release underway, the final linchpin
in getting alpha releases of continuum up and running is the
maven-release and maven-release-manager.

So I am calling a vote to get the maven-release parent pom released
and the maven-release-manager which the continuum-release module makes
use of as well as the maven-release-plugin which is _not_ under the
purview of this vote.

In Staging Repo:
http://people.apache.org/~jmcconnell/org/apache/maven/release

Tags:
http://svn.apache.org/repos/asf/maven/release/tags/

Anyway, lets try this and see how it goes:

72 hrs +1/0/-1.  Cast away! :)

jesse

+1 from me...




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

[vote] release maven-release-1 parent and maven-release-manager-1.0-alpha-1

[Jesse McConnell]

With maven-scm having its latest release underway, the final linchpin
in getting alpha releases of continuum up and running is the
maven-release and maven-release-manager.

So I am calling a vote to get the maven-release parent pom released
and the maven-release-manager which the continuum-release module makes
use of as well as the maven-release-plugin which is _not_ under the
purview of this vote.

In Staging Repo:
http://people.apache.org/~jmcconnell/org/apache/maven/release

Tags:
http://svn.apache.org/repos/asf/maven/release/tags/

Anyway, lets try this and see how it goes:

72 hrs +1/0/-1.  Cast away! :)

jesse

+1 from me...

--
jesse mcconnell
[EMAIL PROTECTED]

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

Re: jar:install goal failure

[Arnaud HERITIER]

I suppose that this is with maven 1.x ?
Which version ?
Which versions of the jar and artifact plugins ?

Arnaud

On 13/04/07, Patrick Schneider <[EMAIL PROTECTED]> wrote:


You might try posing your question to the users' list:
[EMAIL PROTECTED]

Also, it would be helpful to provide some more information, such as stack
traces, error output, POMs, etc.


Patrick

On 4/13/07, Sohan Shetty <[EMAIL PROTECTED] > wrote:
>
> Hi,
>
> We had a properly working in Build System in place.
>
> However, yesterday, when a triggered a build, the JAVA project build
> failed due to the below reason:
> No goal obtained! 'attainGoal: jar: install'
>
> When we ran maven on the JAVA project individually, we obtained the same
> error. We skipped the JAVA project and ran a build on the next project
> inline i.e. an EJB project and it worked fine.
>
> We re-created the Build System but still the issue persists.
>
> Could you provide any pointers as to why this error occurred? Also what
> are the commands which get executed as part of jar: install goal and
> their sequence of execution?
>
> Thanks & Regards,
> Sohan
>
>
>

[Fwd: [VOTE] Release Maven-SCM 1.0-rc1]

[Emmanuel Venisse]

I forward this vote here for people that aren't on scm dev list, but if you 
want to vote, the vote must be done on the scm dev list.

Emmanuel
--- Begin Message ---

Hi,

I'd like to release Maven SCM 1.0-rc1
This version fix few bugs, add a new provider (mercurial) and few commands.

Road Map:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10527&styleName=Html&version=13066

Site:
http://people.apache.org/~evenisse/stage/site/

Staging repo:
http://people.apache.org/~evenisse/stage/repo/

Tag:
http://svn.apache.org/repos/asf/maven/scm/tags/maven-scm-1.0-rc1/

So, let's try 72h +1/+0/-1. Please cast your votes!

Here my +1

Emmanuel





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

Re: jar:install goal failure

[Patrick Schneider]

You might try posing your question to the users' list:
[EMAIL PROTECTED]

Also, it would be helpful to provide some more information, such as stack
traces, error output, POMs, etc.


Patrick

On 4/13/07, Sohan Shetty <[EMAIL PROTECTED] > wrote:


Hi,

We had a properly working in Build System in place.

However, yesterday, when a triggered a build, the JAVA project build
failed due to the below reason:
No goal obtained! 'attainGoal: jar: install'

When we ran maven on the JAVA project individually, we obtained the same
error. We skipped the JAVA project and ran a build on the next project
inline i.e. an EJB project and it worked fine.

We re-created the Build System but still the issue persists.

Could you provide any pointers as to why this error occurred? Also what
are the commands which get executed as part of jar: install goal and
their sequence of execution?

Thanks & Regards,
Sohan

jar:install goal failure

[Sohan Shetty]

Hi,

We had a properly working in Build System in place.

However, yesterday, when a triggered a build, the JAVA project build
failed due to the below reason:
No goal obtained! 'attainGoal: jar: install' 

When we ran maven on the JAVA project individually, we obtained the same
error. We skipped the JAVA project and ran a build on the next project
inline i.e. an EJB project and it worked fine. 

We re-created the Build System but still the issue persists.

Could you provide any pointers as to why this error occurred? Also what
are the commands which get executed as part of jar: install goal and
their sequence of execution?

Thanks & Regards,
Sohan 

Re: [Archetypes] plugin proposition

[Raphaël Piéroni]

Hi,

feel free to steal the code from mojo.
but please, let me be informed as i could still contribute with patches.

Raphaël

2007/4/9, Brett Porter <[EMAIL PROTECTED]>:

I think we should continue to use ARCHETYPE and start planning
towards a 1.0 with the new code base. The current JIRA will need a
clean up to see what issues are still relevant in the new code base,
of course.

- Brett

On 09/04/2007, at 5:02 AM, Franz Allan Valencia See wrote:

> Curious,..
>
> Where is the jira issue(s) for this? ..Can't seem to find them :-)
>
> Thanks,
> Franz
>
> On 4/1/07, Milos Kleint <[EMAIL PROTECTED]> wrote:
>>
>> On 4/1/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>> >
>> > On 1 Apr 07, at 6:49 AM 1 Apr 07, Milos Kleint wrote:
>> >
>> > >>
>> > >
>> > > exactly this is a showstopper for me in the current archetype
>> when I
>> > > attempted to create an archetype for netbeans module
>> development. I
>> > > need to place Bundle.properties and layer.xml file in
>> resources into
>> > > the proper package.
>> > >
>> >
>> > That's fine all we need is the right examples to work against.
>> But in
>> > your case do you just need the final distributable to have
>> resources
>> > in the same package as the classes or do you actually need to
>> > archetype to mix resources with the sources?
>>
>> having the resources in the right place at runtime is fine. I know
>> about targetPath element in resource definition, however I'd rather
>> stay away from that.
>>
>> Often people will need to use both the META-INF/services path and the
>> package named path like: org/codehaus/mevenide/netbeans/xxx.xxx
>> and it
>> becomes non-obvious where to put the services when you define the
>> targetPath.
>>
>> On top of that localization bundles come here as well, these are
>> to be
>> placed in package named path as well, so there's one
>> Bundle.properties
>> for for eac package in the module + some gifs etc. And the form
>> editor
>> in the IDE is not capable of handling the shortened paths. Also the
>> module development file templates can have problems with it.
>>
>> Milos
>>
>>
>> >
>> > Jason.
>> >
>> > > Milos
>> > >
>> > >
>> -
>> > > 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]
>> >
>> >
>>
>> -
>> 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: Change in behavior of maven-archetype-plugin

[Raphaël Piéroni]

2007/4/9, Jason van Zyl <[EMAIL PROTECTED]>:


On 8 Apr 07, at 10:41 PM 8 Apr 07, Brett Porter wrote:

> It seems apparent now that we should push forward with the ng
> stuff. I was going to test if it is at least equivalent to trunk
> and then propose bringing it in to replace trunk and start to plan
> out 1.0 from there.
>

It doesn't work the same yet, the mojos are just stubbed out and I
have yet to get it to create an archetype though the tests are pretty
good so far.


Really please to ear ;)

I will, starting from next week, refactor the descriptor as proposed.

Raphaël




> Does anyone have any bandwidth to help with that?

I will walk through the code in its entirety but not until next week.

Jason.

>
> Thanks,
> Brett
>
> On 09/04/2007, at 12:37 PM, Wendy Smoak wrote:
>
>> On 3/4/07, Wendy Smoak <[EMAIL PROTECTED]> wrote:
>>
>>> The Archetype plugin has lost the ability to "package" non-Java
>>> resources.  It looks like this happened with the addition of 'sub
>>> packages' for Java sources.
>>
>> ping. Any thoughts on whether the problem with "packaging" resources
>> should be fixed in the existing archetype code or whether
>> maven-archetypeng will be ready soon?
>>
>> It's http://jira.codehaus.org/browse/ARCHETYPE-65 .
>>
>> --
>> Wendy
>>
>> -
>> 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]
>
>


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

Re: Deployment properties

[Carlos Sanchez]

that's very ssh specific, more complex scenarios would use archiva and
control there the permissions.

if you want the ssh wagon look for the properties and use them if
present cool, but it'd be easier now to apply and test the patches in
WAGON-19

On 4/13/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:


On 13 Apr 07, at 12:28 PM 13 Apr 07, John Casey wrote:

> so, would the deploy plugin read these properties and set them on
> the wagon
> at deployment time,

Yah, the deployer in maven-artifact would use this and pop the right
things into Wagon.

> or would you have some sort of cron job to keep things
> honest?

If you ran a fix script then any subsequent deployment should obey
the the repository properties.

> I'm guess you'll have to have both, since older versions of the
> deploy plugin won't know to look for the repo.properties...
>

Yah, though it wouldn't take long for a new deploy plugin to circulate.

> Overall, I think it's a decent idea.
>
> -john
>
> On 4/13/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> I'm tired of screwing around with deployments not working with the
>> right permissions and groups. The last fix to the deployments make
>> the permissions decent by default but that's not enough as I deployed
>> something that didn't have a group at all.
>>
>> So I would like to propose using a simple properties file at the root
>> of the server that all deployments will obey. Something like:
>>
>> http://people.apache.org/repo/m2-ibiblio-rsync-repository/maven-
>> repository.properties
>>
>> Just a first though but it's simple and should work. The only thing
>> that would need to be taken into account is a script that would flip
>> everything if you decided to change any of the listed properties. But
>> we could easily make a plugin to generate a script, deploy it and run
>> it.
>>
>> Jason.
>>
>> -
>> 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]





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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

Re: Deployment properties

[Jason van Zyl]

On 13 Apr 07, at 12:28 PM 13 Apr 07, John Casey wrote:

so, would the deploy plugin read these properties and set them on  
the wagon

at deployment time,


Yah, the deployer in maven-artifact would use this and pop the right  
things into Wagon.



or would you have some sort of cron job to keep things
honest?


If you ran a fix script then any subsequent deployment should obey  
the the repository properties.



I'm guess you'll have to have both, since older versions of the
deploy plugin won't know to look for the repo.properties...



Yah, though it wouldn't take long for a new deploy plugin to circulate.


Overall, I think it's a decent idea.

-john

On 4/13/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:


Hi,

I'm tired of screwing around with deployments not working with the
right permissions and groups. The last fix to the deployments make
the permissions decent by default but that's not enough as I deployed
something that didn't have a group at all.

So I would like to propose using a simple properties file at the root
of the server that all deployments will obey. Something like:

http://people.apache.org/repo/m2-ibiblio-rsync-repository/maven-
repository.properties

Just a first though but it's simple and should work. The only thing
that would need to be taken into account is a script that would flip
everything if you decided to change any of the listed properties. But
we could easily make a plugin to generate a script, deploy it and run
it.

Jason.

-
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: Deployment properties

[Jason van Zyl]

On 13 Apr 07, at 12:27 PM 13 Apr 07, Carlos Sanchez wrote:


WAGON-19 and MDEPLOY-28 have patches that would solve the problem with
metadata permissions among others.



We could also just make the properties a little more sophisticated to  
allow for variation. I think just having a reference be looked up and  
used it more maintainable in the long run instead of having to tweak  
all the tools.


Jason.



On 4/13/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:

Hi,

I'm tired of screwing around with deployments not working with the
right permissions and groups. The last fix to the deployments make
the permissions decent by default but that's not enough as I deployed
something that didn't have a group at all.

So I would like to propose using a simple properties file at the root
of the server that all deployments will obey. Something like:

http://people.apache.org/repo/m2-ibiblio-rsync-repository/maven-
repository.properties

Just a first though but it's simple and should work. The only thing
that would need to be taken into account is a script that would flip
everything if you decided to change any of the listed properties. But
we could easily make a plugin to generate a script, deploy it and run
it.

Jason.

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





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

-
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: Deployment properties

[John Casey]

so, would the deploy plugin read these properties and set them on the wagon
at deployment time, or would you have some sort of cron job to keep things
honest? I'm guess you'll have to have both, since older versions of the
deploy plugin won't know to look for the repo.properties...

Overall, I think it's a decent idea.

-john

On 4/13/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:


Hi,

I'm tired of screwing around with deployments not working with the
right permissions and groups. The last fix to the deployments make
the permissions decent by default but that's not enough as I deployed
something that didn't have a group at all.

So I would like to propose using a simple properties file at the root
of the server that all deployments will obey. Something like:

http://people.apache.org/repo/m2-ibiblio-rsync-repository/maven-
repository.properties

Just a first though but it's simple and should work. The only thing
that would need to be taken into account is a script that would flip
everything if you decided to change any of the listed properties. But
we could easily make a plugin to generate a script, deploy it and run
it.

Jason.

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

Re: Deployment properties

[Carlos Sanchez]

WAGON-19 and MDEPLOY-28 have patches that would solve the problem with
metadata permissions among others.


On 4/13/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:

Hi,

I'm tired of screwing around with deployments not working with the
right permissions and groups. The last fix to the deployments make
the permissions decent by default but that's not enough as I deployed
something that didn't have a group at all.

So I would like to propose using a simple properties file at the root
of the server that all deployments will obey. Something like:

http://people.apache.org/repo/m2-ibiblio-rsync-repository/maven-
repository.properties

Just a first though but it's simple and should work. The only thing
that would need to be taken into account is a script that would flip
everything if you decided to change any of the listed properties. But
we could easily make a plugin to generate a script, deploy it and run
it.

Jason.

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





--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

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

Re: perm denied for deploying 2.4-SNAPSHOT of surefire

[Jesse Kuhnert]

Yeah I've got it "mostly" working now with manual metadata removals.

On a side note - it looks like the permissions get written out correctly by
default when I locally modify the snapshotrepo distribution url to use
scpexe:// instead of relying on whatever the default is. (which doesn't
honor group write perms by default I guess)

On 4/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:


only jason can do the chmod or even better run
/www/people.apache.org/repo/m2-snapshot-repository/fix-permissions.sh

if you want to fix it in the meantime, download the metadata files,
delete them in the server and upload again, then run
/www/people.apache.org/repo/m2-snapshot-repository/fix-permissions.sh

On 4/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
> Thanks Carlos!
>
> Seems that this has happened in more than one place (and is also
strangely
> the default behavior of my deploy - though when I do it with tapestry on
the
> same repo it doesn't even ask for my password as I've done the shared
ssh
> key thing ) .
>
> Any chance you could chmod -R g+w everything under surefire ?
>
> On 4/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
> >
> > i just fixed the permissions, it was owned by jason with no group
> > perms, but as the directory is group writable you can delete them and
> > copy again, changing permissions
> >
> > On 4/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
> > > While attempting to deploy the new 2.4 snapshot version of surefire
I
> > got
> > > somewhat far and then ran into a perm denied for one of the metadata
> > files:
> > >
> > > [ERROR] BUILD ERROR
> > > [INFO]
> > >

> > > [INFO] Error installing artifact's metadata: Error while deploying
> > metadata:
> > > SCP terminated with error: 'scp:
> > >
> >
/www/people.apache.org/repo/m2-snapshot-repository/org/apache/maven/surefire/surefire/2.4-SNAPSHOT/maven-
> > > metadata.xml: Permission denied'
> > >
> > > I just ran all the tests against various testng  based maven
projects
> > for
> > > both 5.1 / 5.5 versions of testng and everything is a-ok and ready
to go
> > > from a clean checkout of:
> > >
> > >
> >
https://svn.apache.org/repos/asf/maven/sandbox/branches/surefire/surefire-collaboration
> > >
> > > If anyone else is able to either deploy it for me or add me to the
right
> > > groups it'd be much appreciated.
> > >
> > > (my current group perms on people.apache.org are :)
> > >
> > > uid=2202(jkuhnert) gid=2202(jkuhnert) groups=2202(jkuhnert),
> > 5000(apcvs),
> > > 5004(jakarta), 5035(tapestry)
> > >
> > > --
> > > Jesse Kuhnert
> > > Tapestry/Dojo team member/developer
> > >
> > > Open source based consulting work centered around
> > > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> > >
> >
> >
> > --
> > I could give you my word as a Spaniard.
> > No good. I've known too many Spaniards.
> >  -- The Princess Bride
> >
>
>
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride





--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

Re: perm denied for deploying 2.4-SNAPSHOT of surefire

[Carlos Sanchez]

only jason can do the chmod or even better run
/www/people.apache.org/repo/m2-snapshot-repository/fix-permissions.sh

if you want to fix it in the meantime, download the metadata files,
delete them in the server and upload again, then run
/www/people.apache.org/repo/m2-snapshot-repository/fix-permissions.sh

On 4/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:

Thanks Carlos!

Seems that this has happened in more than one place (and is also strangely
the default behavior of my deploy - though when I do it with tapestry on the
same repo it doesn't even ask for my password as I've done the shared ssh
key thing ) .

Any chance you could chmod -R g+w everything under surefire ?

On 4/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:
>
> i just fixed the permissions, it was owned by jason with no group
> perms, but as the directory is group writable you can delete them and
> copy again, changing permissions
>
> On 4/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
> > While attempting to deploy the new 2.4 snapshot version of surefire I
> got
> > somewhat far and then ran into a perm denied for one of the metadata
> files:
> >
> > [ERROR] BUILD ERROR
> > [INFO]
> > 
> > [INFO] Error installing artifact's metadata: Error while deploying
> metadata:
> > SCP terminated with error: 'scp:
> >
> 
/www/people.apache.org/repo/m2-snapshot-repository/org/apache/maven/surefire/surefire/2.4-SNAPSHOT/maven-
> > metadata.xml: Permission denied'
> >
> > I just ran all the tests against various testng  based maven projects
> for
> > both 5.1 / 5.5 versions of testng and everything is a-ok and ready to go
> > from a clean checkout of:
> >
> >
> 
https://svn.apache.org/repos/asf/maven/sandbox/branches/surefire/surefire-collaboration
> >
> > If anyone else is able to either deploy it for me or add me to the right
> > groups it'd be much appreciated.
> >
> > (my current group perms on people.apache.org are :)
> >
> > uid=2202(jkuhnert) gid=2202(jkuhnert) groups=2202(jkuhnert),
> 5000(apcvs),
> > 5004(jakarta), 5035(tapestry)
> >
> > --
> > Jesse Kuhnert
> > Tapestry/Dojo team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>  -- The Princess Bride
>



--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

Re: perm denied for deploying 2.4-SNAPSHOT of surefire

[Jesse Kuhnert]

nevermind, I get it nowam trying a new deploy now

On 4/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:


Thanks Carlos!

Seems that this has happened in more than one place (and is also strangely
the default behavior of my deploy - though when I do it with tapestry on the
same repo it doesn't even ask for my password as I've done the shared ssh
key thing ) .

Any chance you could chmod -R g+w everything under surefire ?

On 4/13/07, Carlos Sanchez <[EMAIL PROTECTED] > wrote:
>
> i just fixed the permissions, it was owned by jason with no group
> perms, but as the directory is group writable you can delete them and
> copy again, changing permissions
>
> On 4/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
> > While attempting to deploy the new 2.4 snapshot version of surefire I
> got
> > somewhat far and then ran into a perm denied for one of the metadata
> files:
> >
> > [ERROR] BUILD ERROR
> > [INFO]
> >
> 
> > [INFO] Error installing artifact's metadata: Error while deploying
> metadata:
> > SCP terminated with error: 'scp:
> >
> 
/www/people.apache.org/repo/m2-snapshot-repository/org/apache/maven/surefire/surefire/2.4-SNAPSHOT/maven-
> > metadata.xml: Permission denied'
> >
> > I just ran all the tests against various testng  based maven projects
> for
> > both 5.1 / 5.5 versions of testng and everything is a-ok and ready to
> go
> > from a clean checkout of:
> >
> >
> 
https://svn.apache.org/repos/asf/maven/sandbox/branches/surefire/surefire-collaboration
> >
> > If anyone else is able to either deploy it for me or add me to the
> right
> > groups it'd be much appreciated.
> >
> > (my current group perms on people.apache.org are :)
> >
> > uid=2202(jkuhnert) gid=2202(jkuhnert) groups=2202(jkuhnert),
> 5000(apcvs),
> > 5004(jakarta), 5035(tapestry)
> >
> > --
> > Jesse Kuhnert
> > Tapestry/Dojo team member/developer
> >
> > Open source based consulting work centered around
> > dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
> >
>
>
> --
> I could give you my word as a Spaniard.
> No good. I've known too many Spaniards.
>  -- The Princess Bride
>



--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com





--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

Deployment properties

[Jason van Zyl]

Hi,

I'm tired of screwing around with deployments not working with the  
right permissions and groups. The last fix to the deployments make  
the permissions decent by default but that's not enough as I deployed  
something that didn't have a group at all.


So I would like to propose using a simple properties file at the root  
of the server that all deployments will obey. Something like:


http://people.apache.org/repo/m2-ibiblio-rsync-repository/maven- 
repository.properties


Just a first though but it's simple and should work. The only thing  
that would need to be taken into account is a script that would flip  
everything if you decided to change any of the listed properties. But  
we could easily make a plugin to generate a script, deploy it and run  
it.


Jason.

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

Re: perm denied for deploying 2.4-SNAPSHOT of surefire

[Jesse Kuhnert]

Thanks Carlos!

Seems that this has happened in more than one place (and is also strangely
the default behavior of my deploy - though when I do it with tapestry on the
same repo it doesn't even ask for my password as I've done the shared ssh
key thing ) .

Any chance you could chmod -R g+w everything under surefire ?

On 4/13/07, Carlos Sanchez <[EMAIL PROTECTED]> wrote:


i just fixed the permissions, it was owned by jason with no group
perms, but as the directory is group writable you can delete them and
copy again, changing permissions

On 4/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
> While attempting to deploy the new 2.4 snapshot version of surefire I
got
> somewhat far and then ran into a perm denied for one of the metadata
files:
>
> [ERROR] BUILD ERROR
> [INFO]
> 
> [INFO] Error installing artifact's metadata: Error while deploying
metadata:
> SCP terminated with error: 'scp:
>
/www/people.apache.org/repo/m2-snapshot-repository/org/apache/maven/surefire/surefire/2.4-SNAPSHOT/maven-
> metadata.xml: Permission denied'
>
> I just ran all the tests against various testng  based maven projects
for
> both 5.1 / 5.5 versions of testng and everything is a-ok and ready to go
> from a clean checkout of:
>
>
https://svn.apache.org/repos/asf/maven/sandbox/branches/surefire/surefire-collaboration
>
> If anyone else is able to either deploy it for me or add me to the right
> groups it'd be much appreciated.
>
> (my current group perms on people.apache.org are :)
>
> uid=2202(jkuhnert) gid=2202(jkuhnert) groups=2202(jkuhnert),
5000(apcvs),
> 5004(jakarta), 5035(tapestry)
>
> --
> Jesse Kuhnert
> Tapestry/Dojo team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com
>


--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
 -- The Princess Bride





--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jason van Zyl]

On 13 Apr 07, at 11:33 AM 13 Apr 07, ArneD wrote:



Jason,

thanks a lot for your answer.

I did not want to suggest that every Maven user should be forced to  
work
decoupled from repo1. But currently it is much harder than it  
should be, and

this should be improved.


I agree. We really need some simple tools and better documentation  
here as there are many people who do have some simple strategies.


The most common one I know of is one person building everything and  
then flipping the local repository that was populated and turn that  
into the remote repository that the other developers use. You have to  
account for the metadata and we have some tools for this but it's not  
very easy to do. Some nice tools and IDE integration would make this  
very easy to do. It should be seamless.



And I do agree that the separation of the Maven
core and the plugins has its benefits, and the default distribution  
should

be without plugins.

But it should be easy for those who want to work independently of  
central to

do it. Currently it is a pain.


Yes, it is and as a result we have people rsyncing the entire  
repository even though they need only 5% of the contents.


Jason.




Jason van Zyl-2 wrote:



Many even don't want to proxy repo1 but instead manage their own
repository. This is especially true for build artifacts (but it is
also
desirable for Maven plugins which currently would be a pain).

2. Many users don't want to make a distinction between Maven itself
and the
Maven core plugins (compile, jar, ...).


This also not true in my experience. Core plugins are not distributed
with Maven because we have consciously decoupled the lifecycle of
plugins from the core because any plugins we house here may, in fact,
be release two or three times between major releases of Maven and
binding these versions in the core would be a bad idea.



Well, why not release Maven more often then? For those who need a  
freshly

released plugin version urgently, there still could be an override
mechanism.

Eclipse.org makes coordinated releases of many sub-projects. The
sub-projects do have an independent lifecycle, but there are  
coordinated
schedules when bundles are published. So each user knows: Every  
June there's
a new major Eclipse release, and between these releases there's a  
public

visible schedule when new Milestone releases are published.

From a user's point of perspective, this is easy to understand, as  
you don't
*have to* track the versions of all sub-projects like the Platform,  
EMF,
BIRT, ... You still *can* if you want. Users who want to stick to  
stable
versions simply wait until the next major release (published once a  
year in

the case of Eclipse).




Currently, when downloading the
Maven distribution, it is in a way uncomplete as even the core
plugins are
missing.


That is intentional and won't change as the default distribution, but
we certainly could provide another if necessary or better yet provide
decent tooling so that it's very simple to setup Maven + a given
manifest of tools you want for a development team.



+1. Both can be good options.




Again, ultimately what you want is what everyone wants. An easy way
to have an initial setup, yet configurable, and provide rock solid
consistent builds. And that's what we're trying to achieve.



Good!




Making a static glob is not the solution.



Okay, I see that you run into other problems when delivering the  
plugin

versions within the Maven Super POM...

At the end of the day, what I mainly wanted to throw into the  
discussion is:


- Maven should be usable almost out-of-the-box even for those users  
that
want to be completely independent from central. Currently this is  
far too
much pain. I agree to you, better tooling can be a good solution.  
But to me,

this tooling seems to be far away...(?)

- Users (including but not limited to newbies) should be *able* to  
see Maven
+ the main plugins as "The Maven build system", if they so want.  
You should
not force *every* user to keep an eye on the versions of the core,  
all the
plugins and so on. One solution could be to make coordinated  
releases with a

publicly visible and reliable schedule like they do on eclipse.org.




- Provide a downloadable distribution that is completely
independent of
repo1, i.e. a distribution that contains all Maven core plugins (in
form of
a pre-filled local repository, for example) in the latest stable
version



That's entirely possible, and we could definitely do something like
that if was deemed something of value by users.




I think it would indeed be of great value to many users, as long as  
tools

that make it really easy to package it together on your own aren't
available.

- Arne

--
View this message in context: http://www.nabble.com/Remove-auto- 
resolution-of-plugin-versions-from-Maven-2.1- 
tf3560617s177.html#a9981105

Sent from the Maven Developers mailing list archive at Nabble.com.

Re: perm denied for deploying 2.4-SNAPSHOT of surefire

[Carlos Sanchez]

i just fixed the permissions, it was owned by jason with no group
perms, but as the directory is group writable you can delete them and
copy again, changing permissions

On 4/13/07, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:

While attempting to deploy the new 2.4 snapshot version of surefire I got
somewhat far and then ran into a perm denied for one of the metadata files:

[ERROR] BUILD ERROR
[INFO]

[INFO] Error installing artifact's metadata: Error while deploying metadata:
SCP terminated with error: 'scp:
/www/people.apache.org/repo/m2-snapshot-repository/org/apache/maven/surefire/surefire/2.4-SNAPSHOT/maven-
metadata.xml: Permission denied'

I just ran all the tests against various testng  based maven projects for
both 5.1 / 5.5 versions of testng and everything is a-ok and ready to go
from a clean checkout of:

https://svn.apache.org/repos/asf/maven/sandbox/branches/surefire/surefire-collaboration

If anyone else is able to either deploy it for me or add me to the right
groups it'd be much appreciated.

(my current group perms on people.apache.org are :)

uid=2202(jkuhnert) gid=2202(jkuhnert) groups=2202(jkuhnert), 5000(apcvs),
5004(jakarta), 5035(tapestry)

--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com




--
I could give you my word as a Spaniard.
No good. I've known too many Spaniards.
-- The Princess Bride

Re: Remove auto-resolution of plugin versions from Maven 2.1

[ArneD]

Jason,

thanks a lot for your answer.

I did not want to suggest that every Maven user should be forced to work
decoupled from repo1. But currently it is much harder than it should be, and
this should be improved. And I do agree that the separation of the Maven
core and the plugins has its benefits, and the default distribution should
be without plugins.

But it should be easy for those who want to work independently of central to
do it. Currently it is a pain.


Jason van Zyl-2 wrote:
> 
>> Many even don't want to proxy repo1 but instead manage their own
>> repository. This is especially true for build artifacts (but it is  
>> also
>> desirable for Maven plugins which currently would be a pain).
>>
>> 2. Many users don't want to make a distinction between Maven itself  
>> and the
>> Maven core plugins (compile, jar, ...).
> 
> This also not true in my experience. Core plugins are not distributed  
> with Maven because we have consciously decoupled the lifecycle of  
> plugins from the core because any plugins we house here may, in fact,  
> be release two or three times between major releases of Maven and  
> binding these versions in the core would be a bad idea.
> 

Well, why not release Maven more often then? For those who need a freshly
released plugin version urgently, there still could be an override
mechanism.

Eclipse.org makes coordinated releases of many sub-projects. The
sub-projects do have an independent lifecycle, but there are coordinated
schedules when bundles are published. So each user knows: Every June there's
a new major Eclipse release, and between these releases there's a public
visible schedule when new Milestone releases are published.

>From a user's point of perspective, this is easy to understand, as you don't
*have to* track the versions of all sub-projects like the Platform, EMF,
BIRT, ... You still *can* if you want. Users who want to stick to stable
versions simply wait until the next major release (published once a year in
the case of Eclipse).



>> Currently, when downloading the
>> Maven distribution, it is in a way uncomplete as even the core  
>> plugins are
>> missing.
> 
> That is intentional and won't change as the default distribution, but  
> we certainly could provide another if necessary or better yet provide  
> decent tooling so that it's very simple to setup Maven + a given  
> manifest of tools you want for a development team.
> 

+1. Both can be good options.



> Again, ultimately what you want is what everyone wants. An easy way  
> to have an initial setup, yet configurable, and provide rock solid  
> consistent builds. And that's what we're trying to achieve.
> 

Good!



> Making a static glob is not the solution.
> 

Okay, I see that you run into other problems when delivering the plugin
versions within the Maven Super POM... 

At the end of the day, what I mainly wanted to throw into the discussion is:

- Maven should be usable almost out-of-the-box even for those users that
want to be completely independent from central. Currently this is far too
much pain. I agree to you, better tooling can be a good solution. But to me,
this tooling seems to be far away...(?)

- Users (including but not limited to newbies) should be *able* to see Maven
+ the main plugins as "The Maven build system", if they so want. You should
not force *every* user to keep an eye on the versions of the core, all the
plugins and so on. One solution could be to make coordinated releases with a
publicly visible and reliable schedule like they do on eclipse.org.



>> - Provide a downloadable distribution that is completely  
>> independent of
>> repo1, i.e. a distribution that contains all Maven core plugins (in  
>> form of
>> a pre-filled local repository, for example) in the latest stable  
>> version
>>
> 
> That's entirely possible, and we could definitely do something like  
> that if was deemed something of value by users.
> 
> 

I think it would indeed be of great value to many users, as long as tools
that make it really easy to package it together on your own aren't
available.

- Arne

-- 
View this message in context: 
http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a9981105
Sent from the Maven Developers mailing list archive at Nabble.com.


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

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Stephane Nicoll]

On 4/13/07, ArneD <[EMAIL PROTECTED]> wrote:


To adress these issues, may I suggest the following:

- Build Maven distributions that include a super POM that declares the
latest stable(!) version of all core Maven plugins (i.e. the plugins hosted
on maven.apache.org).


That won't work. You couldn't expect a corporate pom to be changed that often.



- Provide a downloadable distribution that is completely independent of
repo1, i.e. a distribution that contains all Maven core plugins (in form of
a pre-filled local repository, for example) in the latest stable version


Not sure I follow but I don't see how it will fix the problem.

Stéphane



Regards
- Arne
--
View this message in context: 
http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a9975501
Sent from the Maven Developers mailing list archive at Nabble.com.


-
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: Remove auto-resolution of plugin versions from Maven 2.1

[Andrew Williams]

Actually, that is an interesting point, it could include that.
Enterprise is aimed more at the development cycle, but that could  
easily include a "known stable and compatible with this toolset"  
maven release.


Andy

On 13 Apr 2007, at 14:01, David Roussel wrote:



Hmm, that's a good idea.  A Maven distribution based on a given Maven
release.  Is this like what "Maven Enterprise" will be?


John Casey wrote:


Sure, my only point was that without this (and the standard packaging
definitions) _nothing_ will work...it's just a gut-level  
uneasiness, not

necessarily a big problem.

On a side note, I think it'd be neat to provide a maven distro  
that has a
small internal repo with the latest releases of the plugins in the  
pom and
jar lifecycles...maybe with the packaging/super-POM in there  
too...then,

you
could always override and get from central. That would make Maven  
almost

offline-proof right out of the box...

-john

On 4/12/07, Hayes, Peter <[EMAIL PROTECTED]> wrote:


Right I get that.  That would be pretty annoying.

Maybe instead of a parent POM, an import facility could be used  
that can

grab the same centralized POM (Multiple-inheritance almost :-).

To John's comment, I don't see this being a big offline challenge  
as this
centralized POM would be a released version that could safely be  
cached

in a
local repository, like any other artifact, i.e. it would follow the
snapshot / release methodology.

Peter

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 10:10 AM
To: Maven Developers List
Subject: RE: Remove auto-resolution of plugin versions from Maven  
2.1


Same here.

-Original Message-
From: Stephane Nicoll [mailto:[EMAIL PROTECTED]
Sent: Thursday, April 12, 2007 9:02 AM
To: Maven Developers List
Subject: Re: Remove auto-resolution of plugin versions from Maven  
2.1


Won't work every time.

We have a corporate pom, it's pretty much stable and it won't change
often. All our projects inherit from that one, it will be a pain to
update
everything every time we would want to upgrade some plug-ins.

Stéphane

On 4/12/07, Hayes, Peter <[EMAIL PROTECTED]> wrote:

I'd like to give my 2 cents on this issue.

Would it be possible to maintain a super POM on repo1 that  
contains a
vetted set of plugin versions and then version that POM  
appropriately

based on new releases of core plugins?  Then it would simply be an
inclusion of a specific parent version in a project POM that would
control which plugins to take.  I think this is what people  
probably
do internally but if it is maintained on repo1, it would save a  
lot of

work for a lot of people.

Peter

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 11, 2007 10:40 PM
To: Maven Developers List
Subject: RE: Remove auto-resolution of plugin versions from  
Maven 2.1



If I need a specific version (usual to workaround a known  
issue) then

I specify it in the the pom. Otherwise I want the latest.
This is the current problem, where builds are done with  
undetermined

versions. (ie the version for dev a might not match dev b)


For snapshot builds if I will use specified, then latest.



For a released build, I want the pom to be transformed and fully
locked down so that the build is reproducible.  And I don't  
want to

do that manually.


I would expect that my snapshot builds to be exactly the same as  
the

eventual release build for that version. The last thing I need is
release to decide for me which versions to use. I do want to do it
manually, because I want to try out each new plugin before I  
bless it
and allow it into the build process for the rest of the team.  
I've had

too many occurrences where a plugin change breaks my build (I'm ok
with that, it's necessary for forward progress). By manually  
vetting a

plugin, it gives me a chance to make any adjustments needed.

It's no different than how we upgrade Maven itself: I have used
enforcer to lock my build to 2.0.5 until I can get all the depMgt
straightened out and then I will move everyone forward.

--- 
--

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]




 
-
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]




 
-

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







--
View this mess

RE: [VOTE] maven-enforcer-plugin:1.0-alpha-2

[Brian E. Fox]

Results:
Binding: +4 (Brian,Luke,Stephane,Arnaud)
Nonbinding: + (Jerome)

-Original Message-
From: Brian E. Fox [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, April 10, 2007 3:40 PM
To: Maven Developers List
Subject: [VOTE] maven-enforcer-plugin:1.0-alpha-2

This release fixes just one critical issue:

Release Notes - Maven 2.x Enforcer Plugin - Version 1.0-alpha-2

** Bug
* [MENFORCER-1] - plugin fails on jdk < 1.5

The deployments are staged here:

http://people.apache.org/~brianf/staging-repository
 

Vote is open for 72hrs.

+1


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

perm denied for deploying 2.4-SNAPSHOT of surefire

[Jesse Kuhnert]

While attempting to deploy the new 2.4 snapshot version of surefire I got
somewhat far and then ran into a perm denied for one of the metadata files:

[ERROR] BUILD ERROR
[INFO]

[INFO] Error installing artifact's metadata: Error while deploying metadata:
SCP terminated with error: 'scp:
/www/people.apache.org/repo/m2-snapshot-repository/org/apache/maven/surefire/surefire/2.4-SNAPSHOT/maven-
metadata.xml: Permission denied'

I just ran all the tests against various testng  based maven projects for
both 5.1 / 5.5 versions of testng and everything is a-ok and ready to go
from a clean checkout of:

https://svn.apache.org/repos/asf/maven/sandbox/branches/surefire/surefire-collaboration

If anyone else is able to either deploy it for me or add me to the right
groups it'd be much appreciated.

(my current group perms on people.apache.org are :)

uid=2202(jkuhnert) gid=2202(jkuhnert) groups=2202(jkuhnert), 5000(apcvs),
5004(jakarta), 5035(tapestry)

--
Jesse Kuhnert
Tapestry/Dojo team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind. http://blog.opencomponentry.com

Re: Remove auto-resolution of plugin versions from Maven 2.1

[Jason van Zyl]

On 13 Apr 07, at 5:10 AM 13 Apr 07, ArneD wrote:



Hi everybody,

from a corporate user's point of view, I believe, the following  
points are

important:

1. Corporate users want to be completely decoupled from what's  
happening on

repo1.


No they don't. In my experience they have wanted to shield all their  
developers from central but generally still have someone who  
maintains a connection to central. Whether they mirror its contents  
inside their firewall, create internal repositories by running builds  
and turning local repos into remote repos for their developers, or  
using a proxy. All three are prevalent use cases.


That corporate users want something consistent and reliable is for  
certain, but cutting off the network effect that Maven provides is  
generally not desirable and defeats one of Maven's greatest virtues  
in that new things are immediately available for use. That we have  
bugs with the snapshot mechanism and not fully worked out patterns  
for versioning of parent POM and plugins just comes with Maven not  
being fully mature but don't throw the baby out with the bath water.



Many even don't want to proxy repo1 but instead manage their own
repository. This is especially true for build artifacts (but it is  
also

desirable for Maven plugins which currently would be a pain).

2. Many users don't want to make a distinction between Maven itself  
and the

Maven core plugins (compile, jar, ...).


This also not true in my experience. Core plugins are not distributed  
with Maven because we have consciously decoupled the lifecycle of  
plugins from the core because any plugins we house here may, in fact,  
be release two or three times between major releases of Maven and  
binding these versions in the core would be a bad idea.



Currently, when downloading the
Maven distribution, it is in a way uncomplete as even the core  
plugins are

missing.


That is intentional and won't change as the default distribution, but  
we certainly could provide another if necessary or better yet provide  
decent tooling so that it's very simple to setup Maven + a given  
manifest of tools you want for a development team.



In contrast, if you download Ant, for example, you get all core ant
tasks. Yes, it it possible to download other tasks from elsewhere,  
but what
you get out-of-the-box contains the most important things. The same  
if you
download the Eclipse SDK. It is not just the Eclipse runtime but  
instead a
bundle of the runtime and plugins. It is good to be able to use new  
plugins
by just declaring them (as long as you have a connection to repo1),  
but the
Maven core plugins should be usable out-of-the-box, without a  
connection to

repo1.


I don't believe this is what most users want. I believe they would be  
more interested in setting up a complete environment for their  
developers and bundling is not very help here. Someone has to manage  
how developers work behind a firewall and this person is generally  
the one who populates an internal repository. Some tooling here would  
be far more useful.




3. Many corporate users prefer to wait for stable releases instead  
of using
beta versions. When using a stable Maven release, say 2.0.6, you  
should get
latest stable (!) versions of Maven plugins. For example, you do  
not want to
use maven-assembly-plugin 2.2-beta1 just because it has been  
uploaded to
ibiblio. But: You want it out-of-the-box. The last thing that  
newbies want
is to be forced to manually find out the latest version numbers and  
declare

them.


This is why we are promoting the requirement of specifying versions  
in addition to making it easy to find out those versions. Many users  
want different versions and we can't accommodate every possibility  
but putting this power in the users hands you can do whatever you like.


We had the notion of a plugin registry which was used locally by a  
developer but not enforceable team wide. I think this is the feature  
people are looking for. Some manifest that can be enforced and used  
as a mixin so that we don't have to bake it into Maven yet something  
we can provide. But we're always going to get a cross-section of  
users who want one thing and not another which is why we generally  
decide something and make everyone do it as the overall benefit to  
the group is higher. If we baked in versions some would complain  
loudly "I have no control over the versions of plugins", or if we  
provided an override mechanism some would expect the manifest to win,  
or the POM to be dominant.


Again, ultimately what you want is what everyone wants. An easy way  
to have an initial setup, yet configurable, and provide rock solid  
consistent builds. And that's what we're trying to achieve. Making a  
static glob is not the solution.





To adress these issues, may I suggest the following:

- Build Maven distributions that include a super POM that declares the
latest stable(!) version of all core Maven plugin

Re: [VOTE] maven-enforcer-plugin:1.0-alpha-2

[Stephane Nicoll]

+1
Stéphane

On 4/13/07, Arnaud HERITIER <[EMAIL PROTECTED]> wrote:

+1

Arnaud

On 13/04/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
>
> I need 1 more PMC please.
>
>
> -Original Message-
> From: Jerome Lacoste [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, April 11, 2007 2:07 AM
> To: Maven Developers List
> Subject: Re: [VOTE] maven-enforcer-plugin:1.0-alpha-2
>
> On 4/10/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> > This release fixes just one critical issue:
> >
> > Release Notes - Maven 2.x Enforcer Plugin - Version 1.0-alpha-2
> >
> > ** Bug
> > * [MENFORCER-1] - plugin fails on jdk < 1.5
> >
> > The deployments are staged here:
> >
> > http://people.apache.org/~brianf/staging-repository
> > 
>
> +1 (tested with jdk > 1.4 )
>
> -
> 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]
>
>



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

Re: [VOTE] maven-enforcer-plugin:1.0-alpha-2

[Arnaud HERITIER]

+1

Arnaud

On 13/04/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:


I need 1 more PMC please.


-Original Message-
From: Jerome Lacoste [mailto:[EMAIL PROTECTED]
Sent: Wednesday, April 11, 2007 2:07 AM
To: Maven Developers List
Subject: Re: [VOTE] maven-enforcer-plugin:1.0-alpha-2

On 4/10/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> This release fixes just one critical issue:
>
> Release Notes - Maven 2.x Enforcer Plugin - Version 1.0-alpha-2
>
> ** Bug
> * [MENFORCER-1] - plugin fails on jdk < 1.5
>
> The deployments are staged here:
>
> http://people.apache.org/~brianf/staging-repository
> 

+1 (tested with jdk > 1.4 )

-
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: [VOTE] maven-enforcer-plugin:1.0-alpha-2

[Lukas Theussl]

+1

You still need one more though...

-Lukas


Brian E. Fox wrote:

I need 1 more PMC please.
 


-Original Message-
From: Jerome Lacoste [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 11, 2007 2:07 AM

To: Maven Developers List
Subject: Re: [VOTE] maven-enforcer-plugin:1.0-alpha-2

On 4/10/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:


This release fixes just one critical issue:

Release Notes - Maven 2.x Enforcer Plugin - Version 1.0-alpha-2

** Bug
   * [MENFORCER-1] - plugin fails on jdk < 1.5

The deployments are staged here:

http://people.apache.org/~brianf/staging-repository




+1 (tested with jdk > 1.4 )

-
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]


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

RE: [VOTE] maven-enforcer-plugin:1.0-alpha-2

[Brian E. Fox]

I need 1 more PMC please.
 

-Original Message-
From: Jerome Lacoste [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, April 11, 2007 2:07 AM
To: Maven Developers List
Subject: Re: [VOTE] maven-enforcer-plugin:1.0-alpha-2

On 4/10/07, Brian E. Fox <[EMAIL PROTECTED]> wrote:
> This release fixes just one critical issue:
>
> Release Notes - Maven 2.x Enforcer Plugin - Version 1.0-alpha-2
>
> ** Bug
> * [MENFORCER-1] - plugin fails on jdk < 1.5
>
> The deployments are staged here:
>
> http://people.apache.org/~brianf/staging-repository
> 

+1 (tested with jdk > 1.4 )

-
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: Remove auto-resolution of plugin versions from Maven 2.1

[David Roussel]

Hmm, that's a good idea.  A Maven distribution based on a given Maven
release.  Is this like what "Maven Enterprise" will be?


John Casey wrote:
> 
> Sure, my only point was that without this (and the standard packaging
> definitions) _nothing_ will work...it's just a gut-level uneasiness, not
> necessarily a big problem.
> 
> On a side note, I think it'd be neat to provide a maven distro that has a
> small internal repo with the latest releases of the plugins in the pom and
> jar lifecycles...maybe with the packaging/super-POM in there too...then,
> you
> could always override and get from central. That would make Maven almost
> offline-proof right out of the box...
> 
> -john
> 
> On 4/12/07, Hayes, Peter <[EMAIL PROTECTED]> wrote:
>>
>> Right I get that.  That would be pretty annoying.
>>
>> Maybe instead of a parent POM, an import facility could be used that can
>> grab the same centralized POM (Multiple-inheritance almost :-).
>>
>> To John's comment, I don't see this being a big offline challenge as this
>> centralized POM would be a released version that could safely be cached
>> in a
>> local repository, like any other artifact, i.e. it would follow the
>> snapshot / release methodology.
>>
>> Peter
>>
>> -Original Message-
>> From: Brian E. Fox [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, April 12, 2007 10:10 AM
>> To: Maven Developers List
>> Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1
>>
>> Same here.
>>
>> -Original Message-
>> From: Stephane Nicoll [mailto:[EMAIL PROTECTED]
>> Sent: Thursday, April 12, 2007 9:02 AM
>> To: Maven Developers List
>> Subject: Re: Remove auto-resolution of plugin versions from Maven 2.1
>>
>> Won't work every time.
>>
>> We have a corporate pom, it's pretty much stable and it won't change
>> often. All our projects inherit from that one, it will be a pain to
>> update
>> everything every time we would want to upgrade some plug-ins.
>>
>> Stéphane
>>
>> On 4/12/07, Hayes, Peter <[EMAIL PROTECTED]> wrote:
>> > I'd like to give my 2 cents on this issue.
>> >
>> > Would it be possible to maintain a super POM on repo1 that contains a
>> > vetted set of plugin versions and then version that POM appropriately
>> > based on new releases of core plugins?  Then it would simply be an
>> > inclusion of a specific parent version in a project POM that would
>> > control which plugins to take.  I think this is what people probably
>> > do internally but if it is maintained on repo1, it would save a lot of
>> > work for a lot of people.
>> >
>> > Peter
>> >
>> > -Original Message-
>> > From: Brian E. Fox [mailto:[EMAIL PROTECTED]
>> > Sent: Wednesday, April 11, 2007 10:40 PM
>> > To: Maven Developers List
>> > Subject: RE: Remove auto-resolution of plugin versions from Maven 2.1
>> >
>> >
>> > >If I need a specific version (usual to workaround a known issue) then
>> > >I specify it in the the pom. Otherwise I want the latest.
>> > This is the current problem, where builds are done with undetermined
>> > versions. (ie the version for dev a might not match dev b)
>> >
>> > >For snapshot builds if I will use specified, then latest.
>> >
>> > >For a released build, I want the pom to be transformed and fully
>> > >locked down so that the build is reproducible.  And I don't want to
>> > >do that manually.
>> >
>> > I would expect that my snapshot builds to be exactly the same as the
>> > eventual release build for that version. The last thing I need is
>> > release to decide for me which versions to use. I do want to do it
>> > manually, because I want to try out each new plugin before I bless it
>> > and allow it into the build process for the rest of the team. I've had
>> > too many occurrences where a plugin change breaks my build (I'm ok
>> > with that, it's necessary for forward progress). By manually vetting a
>> > plugin, it gives me a chance to make any adjustments needed.
>> >
>> > It's no different than how we upgrade Maven itself: I have used
>> > enforcer to lock my build to 2.0.5 until I can get all the depMgt
>> > straightened out and then I will move everyone forward.
>> >
>> > -
>> > 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]
>> >
>> >
>>
>> -
>> 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]
>>
>>
>>
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTEC

Re: Using LDAP for authentication

[Jesse McConnell]

1) my thought would be you don't have a mapping between the principal
and the user assignments in the rbac setup...if that principal isn't
the same between the two systems then your not going to have any
authorization credentials..

2) unless you have the authorization you don't get to see roles to
assign to yourself, are you logged in as the system or user
administrator initially to see these roles?

jesse

On 4/10/07, David Goemans <[EMAIL PROTECTED]> wrote:

Hi,

Now I know, how I can let Continuum only use My implementation (deleted
the JDO-UsermanagerProvider.jar).

But I have other problems:
1. My LDAP-User has no Authorisation (At the moment, I fixed it by
manually db-insert)
2. I could not give my user any new assignments in Web-Front
Effective Roles: shows all roles
Assigned Roles: shows all assigned roles
Available Roles: shows "No Roles Available to Grant" although there are
not assigned roles.

greetz

David

David Goemans schrieb:
> I tried to implement my Class LdapUserManager without extending
> JdoUserManager.
>
> But there are some problems:
>
> I set the hint of my implementation on ldap and changed the Requirements
> of the classes which use a UserManager on my Implementation (hint=ldap).
> But the only class I found where
> "org.apache.maven.continuum.web.action.ProjectGroupAction", but I think
> there must be classes in the Plexus Security (But I don't know how to
> change them)!
>
> After that I tried to give my Implementation the hint jdo (I know it is
> a dirty hack). Know Continuum uses sometimes my implementation and the
> default jdo-implementation.
>
> -David
>
> Joakim Erdfelt schrieb:
>> Some problems here.
>>
>> You can't extend JdoUserManager.
>> That won't work.
>>
>> If you need multiple sources for Users, then that is a feature we need
>> to add to the security framework.
>> We already do this with the Authorization bits.  I see no reason we
>> can't do that for the Authentication bits too.
>>
>> Again, Use the maven 2 build process.
>> Look at the annotations within the code.
>> The 'role-hint' is the key.
>> Your LDAP code will have it's own unique role-hint.
>>
>> Do *NOT* manage the components.xml by hand.
>>
>> - Joakim
>>
>> David Goemans wrote:
>>> Hi,
>>>
>>> at first thanks for your help. I want to write a UserManager, which
>>> extends the JdoUserManager and only search in LDAP if the user isn't
>>> saved in Database.
>>>
>>> But my first problem is that I don't understand, how continuum knows
>>> that it should use my UserManager-implementation.
>>>
>>> - David
>>>
>>> Joakim Erdfelt schrieb:
>>>
 There are 3 database stores for you to worry about.

 Users
 Roles / Permissions / Resouces
 Keys

 If you are just providing Users / Authentication ldap integration, then
 you need only to create an LDAP Provider for the Users Store.

 Use the maven 2 build process and you don't have to manage the
 components.xml manually, as the maven 2 build process creates them from
 annotations within the source code.

 See the examples in source control -
 
https://svn.codehaus.org/plexus/plexus-redback/branches/plexus-security-1.0-alpha-11/user-management/providers/

 - Joakim

 David Goemans wrote:

> yes I am willing to share this implementation. But I didn't write a
> implementation now (only a dummy). At the moment I only want to know
> how to configure it in the component.xml-File. Then I will try to write
> a LDAP-implementation.
>
> greetz
>David
>
> Joakim Erdfelt schrieb:
>
>
>> Would you be willing to share this implementation?
>> As we would all be interested in getting access to this?
>>
>> - Joakim Erdfelt
>>
>> David Goemans wrote:
>>
>>
>>> Hi,
>>>
>>> I want to use LDAP to authenticate on Continuum. I tried to write a own
>>> RBAC-Manager and wanted to configure it in the file "components.xml" of
>>> the subproject continuum-security as follow:
>>>
>>> 
>>> 
>>> org.codehaus.plexus.security.rbac.RBACManager
>>> cached
>>> 
org.codehaus.plexus.security.authorization.rbac.store.cached.CachedRbacManager
>>> CachedRbacManager is a wrapped RBACManager with
>>> caching.
>>> 
>>> 
>>> org.codehaus.plexus.security.rbac.RBACManager
>>> ldap
>>> rbacImpl
>>> 
>>> 
>>> org.codehaus.plexus.ehcache.EhcacheComponent
>>> operations
>>> operationsCache
>>> 
>>> 
>>> org.codehaus.plexus.ehcache.EhcacheComponent
>>> permissions
>>> permissionsCache
>>> 
>>> 
>>> org.codehaus.plexus.ehcache.EhcacheComponent
>>> resources
>>> resourcesCache
>>> 
>>> 
>>> org.codehaus.plexus.ehcache.EhcacheComponent
>>> roles
>>> rolesCache
>>> 
>>> 
>>> 

Re: [VOTE] maven-remote-resources-plugin 1.0-alpha-5

[Joakim Erdfelt]

+1

- Joakim

Daniel Kulp wrote:
> I'd like to release version 1.0-alpha-5 of the 
> maven-remote-resources-plugin.   This resolves one critical bug, but 
> also adds some new features to make it a bit more usable.
>
>
> Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0-alpha-5
>
> ** Bug
> * [MRRESOURCES-18] - Error when no 'inceptionYear' is specified in 
> POM
>
> ** Improvement
> * [MRRESOURCES-19] - Bundle mojo only looks for txt and vm files
> * [MRRESOURCES-20] - Support for binary resources
> * [MRRESOURCES-21] - Supplement the data model used by Velocity
>
>
> Staging area:
> http://people.apache.org/~dkulp/stage_remoteresources/
>
> Tag:
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.0-alpha-5/
>
>   


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

Re: [VOTE] maven-remote-resources-plugin 1.0-alpha-5

[Emmanuel Venisse]

+1

Emmanuel

Daniel Kulp a écrit :
I'd like to release version 1.0-alpha-5 of the 
maven-remote-resources-plugin.   This resolves one critical bug, but 
also adds some new features to make it a bit more usable.



Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0-alpha-5

** Bug
* [MRRESOURCES-18] - Error when no 'inceptionYear' is specified in 
POM


** Improvement
* [MRRESOURCES-19] - Bundle mojo only looks for txt and vm files
* [MRRESOURCES-20] - Support for binary resources
* [MRRESOURCES-21] - Supplement the data model used by Velocity


Staging area:
http://people.apache.org/~dkulp/stage_remoteresources/

Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote-resources-plugin-1.0-alpha-5/




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

Re: [maven-source-plugin] Releasing 2.0.3

[Niall Pemberton]

ping!

Niall

On 4/3/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:


On 3 Apr 07, at 1:39 PM 3 Apr 07, Jochen Wiedmann wrote:

> Hi,
>
> now that Maria has applied MSOURCES-14, can this release proceed?
>

I'll check it with the embedder and a few other projects before I
give it a thumbs up.

jason.

> Thanks,
>
> Jochen
>
>
> --
> My cats know that I am a loser who goes out for hunting every day
> without ever returning as much as a single mouse. Fortunately, I've
> got a wife who's a real champ: She leaves the house and returns within
> half an hour, carrying whole bags full of meal.
>
> -
> 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]




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

Re: [VOTE] maven-remote-resources-plugin 1.0-alpha-5

[Andrew Williams]

+1

On 12 Apr 2007, at 18:13, Daniel Kulp wrote:



I'd like to release version 1.0-alpha-5 of the
maven-remote-resources-plugin.   This resolves one critical bug, but
also adds some new features to make it a bit more usable.


Release Notes - Maven 2.x Remote Resources Plugin - Version 1.0- 
alpha-5


** Bug
* [MRRESOURCES-18] - Error when no 'inceptionYear' is specified in
POM

** Improvement
* [MRRESOURCES-19] - Bundle mojo only looks for txt and vm files
* [MRRESOURCES-20] - Support for binary resources
* [MRRESOURCES-21] - Supplement the data model used by Velocity


Staging area:
http://people.apache.org/~dkulp/stage_remoteresources/

Tag:
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-remote- 
resources-plugin-1.0-alpha-5/


--
J. Daniel Kulp
Principal Engineer
IONA
P: 781-902-8727C: 508-380-7194
[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: Remove auto-resolution of plugin versions from Maven 2.1

[ArneD]

Hi everybody,

from a corporate user's point of view, I believe, the following points are
important:

1. Corporate users want to be completely decoupled from what's happening on
repo1. Many even don't want to proxy repo1 but instead manage their own
repository. This is especially true for build artifacts (but it is also
desirable for Maven plugins which currently would be a pain).

2. Many users don't want to make a distinction between Maven itself and the
Maven core plugins (compile, jar, ...). Currently, when downloading the
Maven distribution, it is in a way uncomplete as even the core plugins are
missing. In contrast, if you download Ant, for example, you get all core ant
tasks. Yes, it it possible to download other tasks from elsewhere, but what
you get out-of-the-box contains the most important things. The same if you
download the Eclipse SDK. It is not just the Eclipse runtime but instead a
bundle of the runtime and plugins. It is good to be able to use new plugins
by just declaring them (as long as you have a connection to repo1), but the
Maven core plugins should be usable out-of-the-box, without a connection to
repo1. 

3. Many corporate users prefer to wait for stable releases instead of using
beta versions. When using a stable Maven release, say 2.0.6, you should get
latest stable (!) versions of Maven plugins. For example, you do not want to
use maven-assembly-plugin 2.2-beta1 just because it has been uploaded to
ibiblio. But: You want it out-of-the-box. The last thing that newbies want
is to be forced to manually find out the latest version numbers and declare
them.


To adress these issues, may I suggest the following:

- Build Maven distributions that include a super POM that declares the
latest stable(!) version of all core Maven plugins (i.e. the plugins hosted
on maven.apache.org).

- Provide a downloadable distribution that is completely independent of
repo1, i.e. a distribution that contains all Maven core plugins (in form of
a pre-filled local repository, for example) in the latest stable version

Regards
- Arne
-- 
View this message in context: 
http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tf3560617s177.html#a9975501
Sent from the Maven Developers mailing list archive at Nabble.com.


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