date:20130725

There are two schools of thought amongst the current members of this
projects PMC.

Without wanting to deliberately tip my hand and reveal where my opinion is,
we would like to solicit the opinions if the community that we serve.

Please give us your thoughts.

The topic is essentially:

Do you want the members of the Maven PMC to be social leaders of the Maven
community, who's actions demonstrate the best community behaviour?

The alternative is that members of the Maven PMC are here purely to
complete the legal requirements that an Apache TLP has delegated to PMCs

This is not black and white... The answer can be grey... And everyone is
human so can make mistakes...

So community, what are you expecting?

- Stephen Connolly

On Thursday, 25 July 2013, wrote:

 Author: jdcasey
 Date: Wed Jul 24 23:21:58 2013
 New Revision: 1506778

 URL: http://svn.apache.org/r1506778
 Log:
 Adding section on PMC standards of community commitment

 Modified:
 maven/site/trunk/content/markdown/project-roles.md

 Modified: maven/site/trunk/content/markdown/project-roles.md
 URL:
 http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778r1=1506777r2=1506778view=diff

 ==
 --- maven/site/trunk/content/markdown/project-roles.md (original)
 +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24
 23:21:58 2013
 @@ -176,6 +176,29 @@ The Project Management Committee has the
  * Voting on release artifacts.
  * !-- TODO: get the rest of these --

 + Standards for Community Commitment
 +
 +In the spirit of supporting the health of our community, Project
 +Management Committee members refrain from actions that subvert the
 +functioning of the committee itself.
 +
 +First, Project Management Committee members should not maintain
 long-running
 +forks of Maven code outside of the project itself. Making significant
 +changes to Maven code outside of the project displays a lack of
 +investment in the community. Additionally, attempting to re-integrate
 +a large number of code changes in bulk overwhelms the ability of
 +volunteers in the community to review (and potentially veto) the
 +changes. This effectively thwarts the policing function of the
 +PMC.
 +
 +Second, Project Management Committee members should not divert
 +work on redesigning, reimplementing, or improving Maven code to
 +alternative projects outside of this community for the purposes of
 +reintroducing them as replacement for existing Maven code. While there
 +is a danger here of falling into a Not Invented Here mentality, new
 projects
 +created by Maven PMC members strictly to replace Maven code should not be
 +allowed.
 +
  ### [Project Management Chair](
 http://www.apache.org/foundation/how-it-works.html#pmc-chair)

  For various legal reasons, there are certain things that the Apache




-- 
Sent from my phone

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Fred Cooke

I really appreciate your regularly inserted pieces of Irish humour and
often chuckle at them! Keep that up! :-)

What matters most to me is not the Apache legal stuff, nor good
behaviour/political correctness, rather it's technical excellence and
honesty in achieving it, even if at the expense of hurting someone's
feelings. They should be adults, after all, and not subject to hurt via
technical correction and discussion, even if firey.

My 2c, but you already know how little I care about stepping on toes,
especially when it comes to release semantics :-)

Fred.

On Thu, Jul 25, 2013 at 3:16 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:

There are two schools of thought amongst the current members of this
projects PMC.

Without wanting to deliberately tip my hand and reveal where my opinion is,
we would like to solicit the opinions if the community that we serve.

Please give us your thoughts.

The topic is essentially:

Do you want the members of the Maven PMC to be social leaders of the Maven
community, who's actions demonstrate the best community behaviour?

The alternative is that members of the Maven PMC are here purely to
complete the legal requirements that an Apache TLP has delegated to PMCs

This is not black and white... The answer can be grey... And everyone is
human so can make mistakes...

So community, what are you expecting?

- Stephen Connolly

On Thursday, 25 July 2013, wrote:

Author: jdcasey
Date: Wed Jul 24 23:21:58 2013
New Revision: 1506778

URL: http://svn.apache.org/r1506778
Log:
Adding section on PMC standards of community commitment

Modified:
maven/site/trunk/content/markdown/project-roles.md

Modified: maven/site/trunk/content/markdown/project-roles.md
URL:

http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778r1=1506777r2=1506778view=diff

==
--- maven/site/trunk/content/markdown/project-roles.md (original)
+++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24
23:21:58 2013
@@ -176,6 +176,29 @@ The Project Management Committee has the
* Voting on release artifacts.
* !-- TODO: get the rest of these --

+ Standards for Community Commitment
+
+In the spirit of supporting the health of our community, Project
+Management Committee members refrain from actions that subvert the
+functioning of the committee itself.
+
+First, Project Management Committee members should not maintain
long-running
+forks of Maven code outside of the project itself. Making significant
+changes to Maven code outside of the project displays a lack of
+investment in the community. Additionally, attempting to re-integrate
+a large number of code changes in bulk overwhelms the ability of
+volunteers in the community to review (and potentially veto) the
+changes. This effectively thwarts the policing function of the
+PMC.
+
+Second, Project Management Committee members should not divert
+work on redesigning, reimplementing, or improving Maven code to
+alternative projects outside of this community for the purposes of
+reintroducing them as replacement for existing Maven code. While there
+is a danger here of falling into a Not Invented Here mentality, new
projects
+created by Maven PMC members strictly to replace Maven code should not
be
+allowed.
+
### [Project Management Chair](
http://www.apache.org/foundation/how-it-works.html#pmc-chair)

For various legal reasons, there are certain things that the Apache

--
Sent from my phone

Re: [VOTE] Release Apache Maven IDEA Plugin version 2.2.1

On 23 July 2013 19:23, Dennis Lundberg dennisl.apa...@gmail.com wrote:
 Hi,

 This is the final release of this plugin. After this release it will
 be retired, see separate vote thread for more info on that.

 We solved 1 issue:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11135styleName=Htmlversion=14478

 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11135status=1

 Staging repo:
 https://repository.apache.org/content/repositories/maven-008/
 https://repository.apache.org/content/repositories/maven-008/org/apache/maven/plugins/maven-idea-plugin/2.2.1/maven-idea-plugin-2.2.1-source-release.zip

 For those interested, the SCM URL can be found in the pom.xml that is
 in the staging repo.

I'm afraid that is all but useless, as the staging repo URL is transitory

Besides, does the POM also contain the revision number? Neither the
Maven PMC nor SVN guarantee immutable tags.

For the benefit of the mailing archives (and completeness of the vote
request), I assume you mean

https://svn.apache.org/repos/asf/maven/plugins/tags/maven-idea-plugin-2.2.1/
(r1506193)

 Staging site:
 http://maven.apache.org/plugins-archives/maven-idea-plugin-2.2.1/

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 --
 Dennis Lundberg

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Model Converter version 2.3

On 23 July 2013 20:45, Dennis Lundberg denn...@apache.org wrote:
 Hi,

 This will be the final release of this shared component. After this
 release it will retire from the Apache Maven project and move to the
 Apache Archiva project. See separate vote thread about that.

 We solved 6 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14389

 There are no issues left in JIRA (except for the one to retire, which
 I'll close later):
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761component=13272status=1

 Staging repo:
 https://repository.apache.org/content/repositories/maven-010/
 https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip

 Staging site (not synced yet):
 http://maven.apache.org/shared-archives/maven-model-converter-2.3/

 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html

What are the unique SCM coordinates?

 Vote open for 72 hours.

 [ ] +1
 [ ] +0
 [ ] -1

 --
 Dennis Lundberg

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plugin testing

2013-07-25 Thread Jason van Zyl


On Jul 25, 2013, at 5:25 AM, Olivier Lamy ol...@apache.org wrote:

 2013/7/23 Jason van Zyl ja...@tesla.io:
 Hi,
 
 I updated the plugin-testing tools to work with Maven 3.1.0 to help Manfred 
 get the Android Maven Plugin's test harness working with 3.1.0. A couple 
 things:
 
 1. There is an @Override for a method implemented for an interface which you 
 can only start doing in Java 1.6 and the compiler was defaulting to 1.5 
 because no target/source were being specific. So I'm not sure if this is a 
 mistake but I set the source/target to 1.6 so that I didn't have to remove 
 the annotation.
 
 2. I should probably bump the version to 3.0.0-SNAPSHOT instead of the 
 2.2-SNAPSHOT, any thoughts here?
 
 sounds good due to the change.
 

Done.

 
 3. And now that I'm working on this I'd like to get it out of Subversion and 
 push it over to Git, any objections? I'd prefer to do that before making a 
 branch for the older version.
 
 
 No objection from me.
 

A JIRA ticket or can I just hop in IRC and ask someone from infra to do it?

 Thanks,
 
 Jason
 
 --
 Jason van Zyl
 Founder,  Apache Maven
 http://twitter.com/jvanzyl
 -
 
 Script timed out
 
 
 
 
 
 
 
 
 
 -- 
 Olivier Lamy
 Ecetera: http://ecetera.com.au
 http://twitter.com/olamy | http://linkedin.com/in/olamy
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org
 

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

happiness is like a butterfly: the more you chase it, the more it will
elude you, but if you turn your attention to other things, it will come
and sit softly on your shoulder ...

-- Thoreau

Re: Plugin testing

2013-07-25 Thread Arnaud Héritier


 
  3. And now that I'm working on this I'd like to get it out of
 Subversion and push it over to Git, any objections? I'd prefer to do that
 before making a branch for the older version.
 
 
  No objection from me.
 

 A JIRA ticket or can I just hop in IRC and ask someone from infra to do it?

 I think you need to fill a ticket like this one :
https://issues.apache.org/jira/browse/INFRA-5266
And then you may try to ping someone on IRC to have a quicker resolution if
possible

cheers

Re: [VOTE] Release Apache Maven Model Converter version 2.3

Den 25 jul 2013 16:08 skrev sebb seb...@gmail.com:

 On 23 July 2013 20:45, Dennis Lundberg denn...@apache.org wrote:
  Hi,
 
  This will be the final release of this shared component. After this
  release it will retire from the Apache Maven project and move to the
  Apache Archiva project. See separate vote thread about that.
 
  We solved 6 issues:
 
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14389
 
  There are no issues left in JIRA (except for the one to retire, which
  I'll close later):
 
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761component=13272status=1
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-010/
 
https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip
 
  Staging site (not synced yet):
  http://maven.apache.org/shared-archives/maven-model-converter-2.3/
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html

 What are the unique SCM coordinates?

The SCM URL can be found in the pom file at the staging repo.

--
Dennis Lundberg


  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  --
  Dennis Lundberg
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org

Re: Plugin testing

2013-07-25 Thread Jason van Zyl

Done.

https://issues.apache.org/jira/browse/INFRA-6591

On Jul 25, 2013, at 11:50 AM, Arnaud Héritier aherit...@gmail.com wrote:

 
 
 3. And now that I'm working on this I'd like to get it out of
 Subversion and push it over to Git, any objections? I'd prefer to do that
 before making a branch for the older version.
 
 
 No objection from me.
 
 
 A JIRA ticket or can I just hop in IRC and ask someone from infra to do it?
 
 I think you need to fill a ticket like this one :
 https://issues.apache.org/jira/browse/INFRA-5266
 And then you may try to ping someone on IRC to have a quicker resolution if
 possible
 
 cheers

Thanks,

Jason

--
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
-

Selfish deeds are the shortest path to self destruction.

 -- The Seven Samuari, Akira Kurosawa

Re: [VOTE] Release Apache Maven Model Converter version 2.3

On 25 July 2013 16:55, Dennis Lundberg denn...@apache.org wrote:
 Den 25 jul 2013 16:08 skrev sebb seb...@gmail.com:

 On 23 July 2013 20:45, Dennis Lundberg denn...@apache.org wrote:
  Hi,
 
  This will be the final release of this shared component. After this
  release it will retire from the Apache Maven project and move to the
  Apache Archiva project. See separate vote thread about that.
 
  We solved 6 issues:
 
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14389
 
  There are no issues left in JIRA (except for the one to retire, which
  I'll close later):
 
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761component=13272status=1
 
  Staging repo:
  https://repository.apache.org/content/repositories/maven-010/
 
 https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip
 
  Staging site (not synced yet):
  http://maven.apache.org/shared-archives/maven-model-converter-2.3/
 
  Guide to testing staged releases:
  http://maven.apache.org/guides/development/guide-testing-releases.html

 What are the unique SCM coordinates?

 The SCM URL can be found in the pom file at the staging repo.

As already mentioned in another thread, the staging repo URL is
temporary (and in fact can be reused for something completely
different).

Nor does it uniquely identify the code in SCM, as the revision is missing.

So it is not suitable for documenting the SCM coordinates.

 --
 Dennis Lundberg


  Vote open for 72 hours.
 
  [ ] +1
  [ ] +0
  [ ] -1
 
  --
  Dennis Lundberg
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Model Converter version 2.3

On Thu, Jul 25, 2013 at 6:34 PM, sebb seb...@gmail.com wrote:
On 25 July 2013 16:55, Dennis Lundberg denn...@apache.org wrote:
Den 25 jul 2013 16:08 skrev sebb seb...@gmail.com:

On 23 July 2013 20:45, Dennis Lundberg denn...@apache.org wrote:
Hi,

This will be the final release of this shared component. After this
release it will retire from the Apache Maven project and move to the
Apache Archiva project. See separate vote thread about that.

We solved 6 issues:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14389

There are no issues left in JIRA (except for the one to retire, which
I'll close later):

http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761component=13272status=1

Staging repo:
https://repository.apache.org/content/repositories/maven-010/

https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip

Staging site (not synced yet):
http://maven.apache.org/shared-archives/maven-model-converter-2.3/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

What are the unique SCM coordinates?

The SCM URL can be found in the pom file at the staging repo.

As already mentioned in another thread, the staging repo URL is
temporary (and in fact can be reused for something completely
different).

Nor does it uniquely identify the code in SCM, as the revision is missing.

So it is not suitable for documenting the SCM coordinates.

In the normal case, where a release is approved on the first round,
there is only ever one tag in SVN and it will not be changed. In these
cases I do not see the value of including the revision number at all.

If a release fails on the first attempt, we reuse the tag. This means
that the tag will exist at multiple revisions. If you are an
archealogist and find out the revision number of an ancient vote, you
can look at the date/time of the vote mail and compare that to the
revision dates in SVN. Still I do not see the value of this. The last
tag standing is the one that got approved.

Is there an ASF requirement to include the SCM revision number in a
release vote? I can't find one.

--
Dennis Lundberg

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

--
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Model Converter version 2.3

On 25 July 2013 17:50, Dennis Lundberg denn...@apache.org wrote:
On Thu, Jul 25, 2013 at 6:34 PM, sebb seb...@gmail.com wrote:
On 25 July 2013 16:55, Dennis Lundberg denn...@apache.org wrote:
Den 25 jul 2013 16:08 skrev sebb seb...@gmail.com:

On 23 July 2013 20:45, Dennis Lundberg denn...@apache.org wrote:
Hi,

This will be the final release of this shared component. After this
release it will retire from the Apache Maven project and move to the
Apache Archiva project. See separate vote thread about that.

We solved 6 issues:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14389

There are no issues left in JIRA (except for the one to retire, which
I'll close later):

http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761component=13272status=1

Staging repo:
https://repository.apache.org/content/repositories/maven-010/

https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip

Staging site (not synced yet):
http://maven.apache.org/shared-archives/maven-model-converter-2.3/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

What are the unique SCM coordinates?

The SCM URL can be found in the pom file at the staging repo.

As already mentioned in another thread, the staging repo URL is
temporary (and in fact can be reused for something completely
different).

Nor does it uniquely identify the code in SCM, as the revision is missing.

So it is not suitable for documenting the SCM coordinates.

Provided that the tag is not accidentally or deliberately changed subsequently.

Is there an ASF requirement to include the SCM revision number in a
release vote? I can't find one.

This was all discussed at great length already; please see my other
postings on the subject.

--
Dennis Lundberg

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

--
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: svn commit: r1506890 - /maven/enforcer/trunk/maven-enforcer-plugin/src/main/java/org/apache/maven/plugins/enforcer/AbstractEnforceMojo.java

On 25 July 2013 12:17,  ol...@apache.org wrote:
 Author: olamy
 Date: Thu Jul 25 11:17:41 2013
 New Revision: 1506890

 URL: http://svn.apache.org/r1506890
 Log:
 Use Apache formatting rules.

pedantic mode
Strictly speaking, these are the Apache Maven formatting rules.
These rules are not the same for all Apache products (thankfully)

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Moving unreleased shared components to the sandbox

2013-07-25 Thread Robert Scholte


Hi Dennis,

I've just started developing the maven-project-utils and I'm planning to  
use it with at least the maven-site-plugin and maven-release-plugin.

Hervé and I have some other complex cases which should be solved here.
Let's keep this one. I first release should be possible this year.

Robert

Op Thu, 25 Jul 2013 00:06:28 +0200 schreef Dennis Lundberg  
denn...@apache.org:



Hi

I've been going through our shared components making sure they all
follow ASF branding rules. While doing this I became curious about a
couple of the components that seemed alien to me. It turns out that of
our 30 shared components we have 5 that have not yet had a release. I
haven't yet looked in svn to see if there has been any recent work on
these 5 components. Here are the components, that haven't yet had a
release:

maven-ant
maven-plugin-enforcer
maven-project-utils
maven-script
maven-shared-monitor

Is anyone working on these?

If not then I think we should move them to the sandbox, until someone
steps up to do a release of them.


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven Model Converter version 2.3

On Thu, Jul 25, 2013 at 7:15 PM, sebb seb...@gmail.com wrote:
On 25 July 2013 17:50, Dennis Lundberg denn...@apache.org wrote:
On Thu, Jul 25, 2013 at 6:34 PM, sebb seb...@gmail.com wrote:
On 25 July 2013 16:55, Dennis Lundberg denn...@apache.org wrote:
Den 25 jul 2013 16:08 skrev sebb seb...@gmail.com:

On 23 July 2013 20:45, Dennis Lundberg denn...@apache.org wrote:
Hi,

This will be the final release of this shared component. After this
release it will retire from the Apache Maven project and move to the
Apache Archiva project. See separate vote thread about that.

We solved 6 issues:

http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=Htmlversion=14389

There are no issues left in JIRA (except for the one to retire, which
I'll close later):

http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761component=13272status=1

Staging repo:
https://repository.apache.org/content/repositories/maven-010/

https://repository.apache.org/content/repositories/maven-010/org/apache/maven/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.zip

Staging site (not synced yet):
http://maven.apache.org/shared-archives/maven-model-converter-2.3/

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

What are the unique SCM coordinates?

The SCM URL can be found in the pom file at the staging repo.

As already mentioned in another thread, the staging repo URL is
temporary (and in fact can be reused for something completely
different).

Nor does it uniquely identify the code in SCM, as the revision is missing.

So it is not suitable for documenting the SCM coordinates.

Provided that the tag is not accidentally or deliberately changed
subsequently.

It is not. That is how we work. The only time we ever manually touch a
tag is when we respin a release.

Is there an ASF requirement to include the SCM revision number in a
release vote? I can't find one.

This was all discussed at great length already; please see my other
postings on the subject.

I'm sorry, but I'm drowning in email at the moment, and have not read
up on all threads.
A simple yes or no answer will suffice for the moment.

--
Dennis Lundberg

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

--
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

--
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Moving unreleased shared components to the sandbox

Sure, no problem.

On Thu, Jul 25, 2013 at 7:44 PM, Robert Scholte rfscho...@apache.org wrote:
 Hi Dennis,

 I've just started developing the maven-project-utils and I'm planning to use
 it with at least the maven-site-plugin and maven-release-plugin.
 Hervé and I have some other complex cases which should be solved here.
 Let's keep this one. I first release should be possible this year.

 Robert

 Op Thu, 25 Jul 2013 00:06:28 +0200 schreef Dennis Lundberg
 denn...@apache.org:


 Hi

 I've been going through our shared components making sure they all
 follow ASF branding rules. While doing this I became curious about a
 couple of the components that seemed alien to me. It turns out that of
 our 30 shared components we have 5 that have not yet had a release. I
 haven't yet looked in svn to see if there has been any recent work on
 these 5 components. Here are the components, that haven't yet had a
 release:

 maven-ant
 maven-plugin-enforcer
 maven-project-utils
 maven-script
 maven-shared-monitor

 Is anyone working on these?

 If not then I think we should move them to the sandbox, until someone
 steps up to do a release of them.


 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+

2013-07-25 Thread Mirko Friedenhagen

+1 non-binding
On Jul 23, 2013 4:00 PM, Stephen Connolly stephen.alan.conno...@gmail.com
wrote:

 This vote is to cover the minimum required version of Java for Maven Core.

 Maven Plugins produced by the Apache Maven Project that are flagged as
 compatible with older versions of Maven Core as their baseline will still
 require to stick to the minimum Java requirements of that Maven Core
 version. In other words, if for example maven-compiler-plugin advertises
 compatibility with Maven Core 2.0.11+ then that will still need to be
 compiled targeting Java 1.4 and only using dependencies that are aligned
 with that runtime requirement.

 Additionally patch releases to existing releases of Maven Core will not be
 subject to this requirement.

 For example [example]*if* this vote passes and *if* on Sep 29th we release
 Maven 3.2.0 and *if* on Oct 2nd we release Maven 2.0.12, Maven 2.2.2, Maven
 3.0.6, Maven 3.1.1, Maven 3.2.1 and Maven 3.3.0 (due to say some security
 issue that affected all versions of Maven) then only Maven 3.3.0 would be
 require Java 6 as a minimum runtime requirement, the 2.0.12 release would
 still require Java 1.4 and the 2.2.2, 3.0.6, 3.1.1 and 3.2.1 versions would
 all still require Java 1.5.[/example]

 This is not a requirement that 3rd party plugins need use Java 6 as a
 minimum. Third party plugins are free to require any Java version = the
 corresponding Maven minimum requirement, though obviously from a users
 perspective it is best if plugins try to adhere to our contracts for
 corresponding versions of Maven Core.

 Justification for the cut-off date:

 * Oracle has gone end of life on Java 6 Feb 2013 (note that there is still
 extended and sustaining support for existing Oracle customers using Java 5)
 * IBM will go end of life for z/OS on 30th Sep 2013 (other platforms are
 still with support, but there are other Java vendors for other platforms)
 * Apple no longer supports any hardware that does not have at least an
 Apple Java 6 version available.
 * Red Hat is providing support for OpenJDK 6
 * HP-UX, OpenVMS, and Tru64 all have a Java 6 implementation available.

 As I see it, that essentially ensures that for the vast majority of
 platforms there is a very strong likelihood of a Java 6 compatible version
 of Java available for that platform. Toolchains support or forking of the
 compiler and surefire can provide support for users who still need to build
 with older versions of Java (e.g., as was the case for Java 1.4.2 with
 Maven 2.2.1). Additionally users who are forced to use a java version older
 than Java 6 also are likely unable to upgrade their version of Maven, so
 this change will not affect them

 This vote is open for 72 hours. A minimum of three +1 binding votes (i.e.
 from the PMC) and the majority of votes cast from committers will be
 required to pass this vote.

 +1000: Yes, and when can we have the vote to go for Java 7 as a minimum?
 (This option is equivalent to +1 but provides people the ability to
 indicate an additional preference while not contributing to the inevitible
 noise)
 +1: Yes
 0: No opinion
 -1: No

 -Stephen

Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+

2013-07-25 Thread Andreas Gudian

+1 non-binding


2013/7/25 Mirko Friedenhagen mfriedenha...@gmail.com

 +1 non-binding
 On Jul 23, 2013 4:00 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com
 wrote:

  This vote is to cover the minimum required version of Java for Maven
 Core.
 
  Maven Plugins produced by the Apache Maven Project that are flagged as
  compatible with older versions of Maven Core as their baseline will still
  require to stick to the minimum Java requirements of that Maven Core
  version. In other words, if for example maven-compiler-plugin advertises
  compatibility with Maven Core 2.0.11+ then that will still need to be
  compiled targeting Java 1.4 and only using dependencies that are aligned
  with that runtime requirement.
 
  Additionally patch releases to existing releases of Maven Core will not
 be
  subject to this requirement.
 
  For example [example]*if* this vote passes and *if* on Sep 29th we
 release
  Maven 3.2.0 and *if* on Oct 2nd we release Maven 2.0.12, Maven 2.2.2,
 Maven
  3.0.6, Maven 3.1.1, Maven 3.2.1 and Maven 3.3.0 (due to say some security
  issue that affected all versions of Maven) then only Maven 3.3.0 would be
  require Java 6 as a minimum runtime requirement, the 2.0.12 release would
  still require Java 1.4 and the 2.2.2, 3.0.6, 3.1.1 and 3.2.1 versions
 would
  all still require Java 1.5.[/example]
 
  This is not a requirement that 3rd party plugins need use Java 6 as a
  minimum. Third party plugins are free to require any Java version = the
  corresponding Maven minimum requirement, though obviously from a users
  perspective it is best if plugins try to adhere to our contracts for
  corresponding versions of Maven Core.
 
  Justification for the cut-off date:
 
  * Oracle has gone end of life on Java 6 Feb 2013 (note that there is
 still
  extended and sustaining support for existing Oracle customers using Java
 5)
  * IBM will go end of life for z/OS on 30th Sep 2013 (other platforms are
  still with support, but there are other Java vendors for other platforms)
  * Apple no longer supports any hardware that does not have at least an
  Apple Java 6 version available.
  * Red Hat is providing support for OpenJDK 6
  * HP-UX, OpenVMS, and Tru64 all have a Java 6 implementation available.
 
  As I see it, that essentially ensures that for the vast majority of
  platforms there is a very strong likelihood of a Java 6 compatible
 version
  of Java available for that platform. Toolchains support or forking of the
  compiler and surefire can provide support for users who still need to
 build
  with older versions of Java (e.g., as was the case for Java 1.4.2 with
  Maven 2.2.1). Additionally users who are forced to use a java version
 older
  than Java 6 also are likely unable to upgrade their version of Maven, so
  this change will not affect them
 
  This vote is open for 72 hours. A minimum of three +1 binding votes (i.e.
  from the PMC) and the majority of votes cast from committers will be
  required to pass this vote.
 
  +1000: Yes, and when can we have the vote to go for Java 7 as a minimum?
  (This option is equivalent to +1 but provides people the ability to
  indicate an additional preference while not contributing to the
 inevitible
  noise)
  +1: Yes
  0: No opinion
  -1: No
 
  -Stephen

Re: [VOTE] All new (non-patch) releases of Maven Core after 30th Sep 2013 to require Java 6+

2013-07-25 Thread Robert Scholte


+1

Op Tue, 23 Jul 2013 15:59:49 +0200 schreef Stephen Connolly  
stephen.alan.conno...@gmail.com:


This vote is to cover the minimum required version of Java for Maven  
Core.


Maven Plugins produced by the Apache Maven Project that are flagged as
compatible with older versions of Maven Core as their baseline will still
require to stick to the minimum Java requirements of that Maven Core
version. In other words, if for example maven-compiler-plugin advertises
compatibility with Maven Core 2.0.11+ then that will still need to be
compiled targeting Java 1.4 and only using dependencies that are aligned
with that runtime requirement.

Additionally patch releases to existing releases of Maven Core will not  
be

subject to this requirement.

For example [example]*if* this vote passes and *if* on Sep 29th we  
release
Maven 3.2.0 and *if* on Oct 2nd we release Maven 2.0.12, Maven 2.2.2,  
Maven

3.0.6, Maven 3.1.1, Maven 3.2.1 and Maven 3.3.0 (due to say some security
issue that affected all versions of Maven) then only Maven 3.3.0 would be
require Java 6 as a minimum runtime requirement, the 2.0.12 release would
still require Java 1.4 and the 2.2.2, 3.0.6, 3.1.1 and 3.2.1 versions  
would

all still require Java 1.5.[/example]

This is not a requirement that 3rd party plugins need use Java 6 as a
minimum. Third party plugins are free to require any Java version = the
corresponding Maven minimum requirement, though obviously from a users
perspective it is best if plugins try to adhere to our contracts for
corresponding versions of Maven Core.

Justification for the cut-off date:

* Oracle has gone end of life on Java 6 Feb 2013 (note that there is  
still
extended and sustaining support for existing Oracle customers using Java  
5)

* IBM will go end of life for z/OS on 30th Sep 2013 (other platforms are
still with support, but there are other Java vendors for other platforms)
* Apple no longer supports any hardware that does not have at least an
Apple Java 6 version available.
* Red Hat is providing support for OpenJDK 6
* HP-UX, OpenVMS, and Tru64 all have a Java 6 implementation available.

As I see it, that essentially ensures that for the vast majority of
platforms there is a very strong likelihood of a Java 6 compatible  
version

of Java available for that platform. Toolchains support or forking of the
compiler and surefire can provide support for users who still need to  
build

with older versions of Java (e.g., as was the case for Java 1.4.2 with
Maven 2.2.1). Additionally users who are forced to use a java version  
older

than Java 6 also are likely unable to upgrade their version of Maven, so
this change will not affect them

This vote is open for 72 hours. A minimum of three +1 binding votes (i.e.
from the PMC) and the majority of votes cast from committers will be
required to pass this vote.

+1000: Yes, and when can we have the vote to go for Java 7 as a minimum?
(This option is equivalent to +1 but provides people the ability to
indicate an additional preference while not contributing to the  
inevitible

noise)
+1: Yes
0: No opinion
-1: No

-Stephen


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Stephen Colebourne

The section that was added below has nothing to do with the rest of
the document. It should be reverted, as it is basically nonsense as
Jason has just pointed out.

Maven has lots of other problems. This really doesn't seem like one
anyone should be spending any time or energy on.

Stephen

On 25 July 2013 14:16, Stephen Connolly stephen.alan.conno...@gmail.com wrote:
There are two schools of thought amongst the current members of this
projects PMC.

Without wanting to deliberately tip my hand and reveal where my opinion is,
we would like to solicit the opinions if the community that we serve.

Please give us your thoughts.

The topic is essentially:

Do you want the members of the Maven PMC to be social leaders of the Maven
community, who's actions demonstrate the best community behaviour?

The alternative is that members of the Maven PMC are here purely to
complete the legal requirements that an Apache TLP has delegated to PMCs

This is not black and white... The answer can be grey... And everyone is
human so can make mistakes...

So community, what are you expecting?

- Stephen Connolly

On Thursday, 25 July 2013, wrote:

Author: jdcasey
Date: Wed Jul 24 23:21:58 2013
New Revision: 1506778

URL: http://svn.apache.org/r1506778
Log:
Adding section on PMC standards of community commitment

Modified:
maven/site/trunk/content/markdown/project-roles.md

Modified: maven/site/trunk/content/markdown/project-roles.md
URL:
http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778r1=1506777r2=1506778view=diff

+ Standards for Community Commitment
+
+In the spirit of supporting the health of our community, Project
+Management Committee members refrain from actions that subvert the
+functioning of the committee itself.
+
+First, Project Management Committee members should not maintain
long-running
+forks of Maven code outside of the project itself. Making significant
+changes to Maven code outside of the project displays a lack of
+investment in the community. Additionally, attempting to re-integrate
+a large number of code changes in bulk overwhelms the ability of
+volunteers in the community to review (and potentially veto) the
+changes. This effectively thwarts the policing function of the
+PMC.
+
+Second, Project Management Committee members should not divert
+work on redesigning, reimplementing, or improving Maven code to
+alternative projects outside of this community for the purposes of
+reintroducing them as replacement for existing Maven code. While there
+is a danger here of falling into a Not Invented Here mentality, new
projects
+created by Maven PMC members strictly to replace Maven code should not be
+allowed.
+
### [Project Management Chair](
http://www.apache.org/foundation/how-it-works.html#pmc-chair)

For various legal reasons, there are certain things that the Apache

--
Sent from my phone

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Thomas Broyer

I think I'm with Ron Wheeler here.

I'd add though: are you a “Project Manager” if you don't contribute to
the project the changes you're doing in a fork? My gut feeling would
be “no”, but that'd be ignoring the amount of contributions to the
project itself (I know who you're talking about, but I have no idea
what his implication in Maven proper is).

Also, AFAICT, the long running fork (at least 2 years) is not open
source (parts of it are, not everything) so it's hard to know what
will come out of it and when, and how much implication the PMC member
has in each project.

Also, the fork website says there's no intent in forking Maven (but
rather build upon it).
Or am I wrong about what's and who's being pointed at under cover?

I can hardly comment more than that, being ignorant of what happens on
the Maven Dev list. If the PMC member being pointed at here is who I
think he is, then I have no other problem with his work than not being
open source (and apparently not a proprietary non-free product
either), and creating dissension in the PMC.

That being said, the more I use Maven, the more I think it's “broken
by design”, and there's unfortunately nothing better out there with a
big-enough community to compete.
http://blog.ltgt.net/in-quest-of-the-ultimate-build-tool
I wouldn't really mind if Maven collapsed like others here “predict”,
I'd just switch to another contender (Gradle probably) that's just
different more than being better.
So in the end, don't give too much weight to my opinion here ;-)

On Thu, Jul 25, 2013 at 3:16 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
 There are two schools of thought amongst the current members of this
 projects PMC.

 Without wanting to deliberately tip my hand and reveal where my opinion is,
 we would like to solicit the opinions if the community that we serve.

 Please give us your thoughts.

 The topic is essentially:

 Do you want the members of the Maven PMC to be social leaders of the Maven
 community, who's actions demonstrate the best community behaviour?

 The alternative is that members of the Maven PMC are here purely to
 complete the legal requirements that an Apache TLP has delegated to PMCs

 This is not black and white... The answer can be grey... And everyone is
 human so can make mistakes...

 So community, what are you expecting?

 - Stephen Connolly

 On Thursday, 25 July 2013, wrote:

 Author: jdcasey
 Date: Wed Jul 24 23:21:58 2013
 New Revision: 1506778

 URL: http://svn.apache.org/r1506778
 Log:
 Adding section on PMC standards of community commitment

 Modified:
 maven/site/trunk/content/markdown/project-roles.md

 Modified: maven/site/trunk/content/markdown/project-roles.md
 URL:
 http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778r1=1506777r2=1506778view=diff

 ==
 --- maven/site/trunk/content/markdown/project-roles.md (original)
 +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24
 23:21:58 2013
 @@ -176,6 +176,29 @@ The Project Management Committee has the
  * Voting on release artifacts.
  * !-- TODO: get the rest of these --

 + Standards for Community Commitment
 +
 +In the spirit of supporting the health of our community, Project
 +Management Committee members refrain from actions that subvert the
 +functioning of the committee itself.
 +
 +First, Project Management Committee members should not maintain
 long-running
 +forks of Maven code outside of the project itself. Making significant
 +changes to Maven code outside of the project displays a lack of
 +investment in the community. Additionally, attempting to re-integrate
 +a large number of code changes in bulk overwhelms the ability of
 +volunteers in the community to review (and potentially veto) the
 +changes. This effectively thwarts the policing function of the
 +PMC.
 +
 +Second, Project Management Committee members should not divert
 +work on redesigning, reimplementing, or improving Maven code to
 +alternative projects outside of this community for the purposes of
 +reintroducing them as replacement for existing Maven code. While there
 +is a danger here of falling into a Not Invented Here mentality, new
 projects
 +created by Maven PMC members strictly to replace Maven code should not be
 +allowed.
 +
  ### [Project Management Chair](
 http://www.apache.org/foundation/how-it-works.html#pmc-chair)

  For various legal reasons, there are certain things that the Apache




 --
 Sent from my phone



-- 
Thomas Broyer
/tɔ.ma.bʁwa.je/

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

AW: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Markus Karg

As a Maven user I think that everybody who is working on a project should 
behave the same. Hence, I would say, PMC members should rather certainly 
demonstrate how to live the community rules.

-Ursprüngliche Nachricht-
Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com] 
Gesendet: Donnerstag, 25. Juli 2013 15:16
An: Maven Users List; Maven Developers List
Betreff: [DISCUSS] Should the Maven PMC be an example of how we want the Maven 
Community to behave (was Re: svn commit: r1506778 - 
/maven/site/trunk/content/markdown/project-roles.md)

There are two schools of thought amongst the current members of this projects 
PMC.

Without wanting to deliberately tip my hand and reveal where my opinion is, we 
would like to solicit the opinions if the community that we serve.

Please give us your thoughts.

The topic is essentially:

Do you want the members of the Maven PMC to be social leaders of the Maven 
community, who's actions demonstrate the best community behaviour?

The alternative is that members of the Maven PMC are here purely to complete 
the legal requirements that an Apache TLP has delegated to PMCs

This is not black and white... The answer can be grey... And everyone is human 
so can make mistakes...

So community, what are you expecting?

- Stephen Connolly

On Thursday, 25 July 2013, wrote:

 Author: jdcasey
 Date: Wed Jul 24 23:21:58 2013
 New Revision: 1506778

 URL: http://svn.apache.org/r1506778
 Log:
 Adding section on PMC standards of community commitment

 Modified:
 maven/site/trunk/content/markdown/project-roles.md

 Modified: maven/site/trunk/content/markdown/project-roles.md
 URL:
 http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project
 -roles.md?rev=1506778r1=1506777r2=1506778view=diff

 ==
 
 --- maven/site/trunk/content/markdown/project-roles.md (original)
 +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24
 23:21:58 2013
 @@ -176,6 +176,29 @@ The Project Management Committee has the
  * Voting on release artifacts.
  * !-- TODO: get the rest of these --

 + Standards for Community Commitment
 +
 +In the spirit of supporting the health of our community, Project 
 +Management Committee members refrain from actions that subvert the 
 +functioning of the committee itself.
 +
 +First, Project Management Committee members should not maintain
 long-running
 +forks of Maven code outside of the project itself. Making significant 
 +changes to Maven code outside of the project displays a lack of 
 +investment in the community. Additionally, attempting to re-integrate 
 +a large number of code changes in bulk overwhelms the ability of 
 +volunteers in the community to review (and potentially veto) the 
 +changes. This effectively thwarts the policing function of the PMC.
 +
 +Second, Project Management Committee members should not divert work 
 +on redesigning, reimplementing, or improving Maven code to 
 +alternative projects outside of this community for the purposes of 
 +reintroducing them as replacement for existing Maven code. While 
 +there is a danger here of falling into a Not Invented Here mentality, 
 +new
 projects
 +created by Maven PMC members strictly to replace Maven code should 
 +not be allowed.
 +
  ### [Project Management Chair](
 http://www.apache.org/foundation/how-it-works.html#pmc-chair)

  For various legal reasons, there are certain things that the Apache




--
Sent from my phone

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

maven-enforcer pull request: MENFORCER-159 Add goal recommend which will on...

2013-07-25 Thread mfriedenhagen

Github user mfriedenhagen closed the pull request at:

https://github.com/apache/maven-enforcer/pull/4


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

maven-enforcer pull request: MENFORCER-160 Add levels ERROR and WARN to enf...

2013-07-25 Thread mfriedenhagen

Github user mfriedenhagen closed the pull request at:

https://github.com/apache/maven-enforcer/pull/5


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

I don't think it is possible to force volunteer efforts and/or limit
development elsewhere. The idea of supporting a project is a vague notion.
I have my opinions too but this language is clearly unenforceable and
impractical.

Cheers,
Paul


On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg k...@quipsy.de wrote:

 As a Maven user I think that everybody who is working on a project should
 behave the same. Hence, I would say, PMC members should rather certainly
 demonstrate how to live the community rules.

 -Ursprüngliche Nachricht-
 Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
 Gesendet: Donnerstag, 25. Juli 2013 15:16
 An: Maven Users List; Maven Developers List
 Betreff: [DISCUSS] Should the Maven PMC be an example of how we want the
 Maven Community to behave (was Re: svn commit: r1506778 -
 /maven/site/trunk/content/markdown/project-roles.md)

 There are two schools of thought amongst the current members of this
 projects PMC.

 Without wanting to deliberately tip my hand and reveal where my opinion
 is, we would like to solicit the opinions if the community that we serve.

 Please give us your thoughts.

 The topic is essentially:

 Do you want the members of the Maven PMC to be social leaders of the Maven
 community, who's actions demonstrate the best community behaviour?

 The alternative is that members of the Maven PMC are here purely to
 complete the legal requirements that an Apache TLP has delegated to PMCs

 This is not black and white... The answer can be grey... And everyone is
 human so can make mistakes...

 So community, what are you expecting?

 - Stephen Connolly

 On Thursday, 25 July 2013, wrote:

  Author: jdcasey
  Date: Wed Jul 24 23:21:58 2013
  New Revision: 1506778
 
  URL: http://svn.apache.org/r1506778
  Log:
  Adding section on PMC standards of community commitment
 
  Modified:
  maven/site/trunk/content/markdown/project-roles.md
 
  Modified: maven/site/trunk/content/markdown/project-roles.md
  URL:
  http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project
  -roles.md?rev=1506778r1=1506777r2=1506778view=diff
 
  ==
  
  --- maven/site/trunk/content/markdown/project-roles.md (original)
  +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24
  23:21:58 2013
  @@ -176,6 +176,29 @@ The Project Management Committee has the
   * Voting on release artifacts.
   * !-- TODO: get the rest of these --
 
  + Standards for Community Commitment
  +
  +In the spirit of supporting the health of our community, Project
  +Management Committee members refrain from actions that subvert the
  +functioning of the committee itself.
  +
  +First, Project Management Committee members should not maintain
  long-running
  +forks of Maven code outside of the project itself. Making significant
  +changes to Maven code outside of the project displays a lack of
  +investment in the community. Additionally, attempting to re-integrate
  +a large number of code changes in bulk overwhelms the ability of
  +volunteers in the community to review (and potentially veto) the
  +changes. This effectively thwarts the policing function of the PMC.
  +
  +Second, Project Management Committee members should not divert work
  +on redesigning, reimplementing, or improving Maven code to
  +alternative projects outside of this community for the purposes of
  +reintroducing them as replacement for existing Maven code. While
  +there is a danger here of falling into a Not Invented Here mentality,
  +new
  projects
  +created by Maven PMC members strictly to replace Maven code should
  +not be allowed.
  +
   ### [Project Management Chair](
  http://www.apache.org/foundation/how-it-works.html#pmc-chair)
 
   For various legal reasons, there are certain things that the Apache
 
 
 

 --
 Sent from my phone

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
Cheers,
Paul

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Baptiste MATHUS

Hi,
I think the point is quite simple.
I agree with Jason that work should be the main criteria if not the only
one.
But as Stephen reminds, we should define work in a larger general sense
than just code. Working for the community as worshipped by the ASF can be
pushing code, sure, but also helping people in many manners : docs, ml, etc.

Cheers
Le 25 juil. 2013 22:32, Paul Benedict pbened...@apache.org a écrit :

 I don't think it is possible to force volunteer efforts and/or limit
 development elsewhere. The idea of supporting a project is a vague notion.
 I have my opinions too but this language is clearly unenforceable and
 impractical.

 Cheers,
 Paul


 On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg k...@quipsy.de wrote:

  As a Maven user I think that everybody who is working on a project should
  behave the same. Hence, I would say, PMC members should rather certainly
  demonstrate how to live the community rules.
 
  -Ursprüngliche Nachricht-
  Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
  Gesendet: Donnerstag, 25. Juli 2013 15:16
  An: Maven Users List; Maven Developers List
  Betreff: [DISCUSS] Should the Maven PMC be an example of how we want the
  Maven Community to behave (was Re: svn commit: r1506778 -
  /maven/site/trunk/content/markdown/project-roles.md)
 
  There are two schools of thought amongst the current members of this
  projects PMC.
 
  Without wanting to deliberately tip my hand and reveal where my opinion
  is, we would like to solicit the opinions if the community that we serve.
 
  Please give us your thoughts.
 
  The topic is essentially:
 
  Do you want the members of the Maven PMC to be social leaders of the
 Maven
  community, who's actions demonstrate the best community behaviour?
 
  The alternative is that members of the Maven PMC are here purely to
  complete the legal requirements that an Apache TLP has delegated to PMCs
 
  This is not black and white... The answer can be grey... And everyone is
  human so can make mistakes...
 
  So community, what are you expecting?
 
  - Stephen Connolly
 
  On Thursday, 25 July 2013, wrote:
 
   Author: jdcasey
   Date: Wed Jul 24 23:21:58 2013
   New Revision: 1506778
  
   URL: http://svn.apache.org/r1506778
   Log:
   Adding section on PMC standards of community commitment
  
   Modified:
   maven/site/trunk/content/markdown/project-roles.md
  
   Modified: maven/site/trunk/content/markdown/project-roles.md
   URL:
   http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project
   -roles.md?rev=1506778r1=1506777r2=1506778view=diff
  
   ==
   
   --- maven/site/trunk/content/markdown/project-roles.md (original)
   +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24
   23:21:58 2013
   @@ -176,6 +176,29 @@ The Project Management Committee has the
* Voting on release artifacts.
* !-- TODO: get the rest of these --
  
   + Standards for Community Commitment
   +
   +In the spirit of supporting the health of our community, Project
   +Management Committee members refrain from actions that subvert the
   +functioning of the committee itself.
   +
   +First, Project Management Committee members should not maintain
   long-running
   +forks of Maven code outside of the project itself. Making significant
   +changes to Maven code outside of the project displays a lack of
   +investment in the community. Additionally, attempting to re-integrate
   +a large number of code changes in bulk overwhelms the ability of
   +volunteers in the community to review (and potentially veto) the
   +changes. This effectively thwarts the policing function of the PMC.
   +
   +Second, Project Management Committee members should not divert work
   +on redesigning, reimplementing, or improving Maven code to
   +alternative projects outside of this community for the purposes of
   +reintroducing them as replacement for existing Maven code. While
   +there is a danger here of falling into a Not Invented Here mentality,
   +new
   projects
   +created by Maven PMC members strictly to replace Maven code should
   +not be allowed.
   +
### [Project Management Chair](
   http://www.apache.org/foundation/how-it-works.html#pmc-chair)
  
For various legal reasons, there are certain things that the Apache
  
  
  
 
  --
  Sent from my phone
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
  For additional commands, e-mail: dev-h...@maven.apache.org
 
 


 --
 Cheers,
 Paul

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

Perhaps we could reframe the question a little then (as people seem to be
testing hung up on the committed wording)...

Should the PMC encourage people experimenting on new improvements to Maven
to do that work at the ASF? And if so, should they then practice what they
preach, and ensure that any experiments with Maven take place on the ASF
SCM servers (at least once such experiments become semi-serious or progress
enough not to cause egg-on-face syndrome)?

Shoud the PMC promote other Apache projects, or moving non-Apache projects
to Apache? (Right now, to work on an issue in core and effect the change
yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
fine with half of these at Eclipse and the ther half here... Or maybe
not... But that is a lot of projects where you need to establish merit and
perhaps maintain merit just to be able to commit directly (which sometimes
is the only way to effect the type of cross system changes that some of our
more obscure bugs may require... GIT makes this less of a requirement, as
patches on SVN are a PITA, though) )

These types of questions need resolution as they will, further down the
road, rise up again and cause wounds... Eg logback vs log4j2 is one that
simmers at the edge (any time anyone mentioned coloured loggers)

-Stephen

On Thursday, 25 July 2013, Paul Benedict wrote:

 I don't think it is possible to force volunteer efforts and/or limit
 development elsewhere. The idea of supporting a project is a vague notion.
 I have my opinions too but this language is clearly unenforceable and
 impractical.

 Cheers,
 Paul


 On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg k...@quipsy.de wrote:

  As a Maven user I think that everybody who is working on a project should
  behave the same. Hence, I would say, PMC members should rather certainly
  demonstrate how to live the community rules.
 
  -Ursprüngliche Nachricht-
  Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
  Gesendet: Donnerstag, 25. Juli 2013 15:16
  An: Maven Users List; Maven Developers List
  Betreff: [DISCUSS] Should the Maven PMC be an example of how we want the
  Maven Community to behave (was Re: svn commit: r1506778 -
  /maven/site/trunk/content/markdown/project-roles.md)
 
  There are two schools of thought amongst the current members of this
  projects PMC.
 
  Without wanting to deliberately tip my hand and reveal where my opinion
  is, we would like to solicit the opinions if the community that we serve.
 
  Please give us your thoughts.
 
  The topic is essentially:
 
  Do you want the members of the Maven PMC to be social leaders of the
 Maven
  community, who's actions demonstrate the best community behaviour?
 
  The alternative is that members of the Maven PMC are here purely to
  complete the legal requirements that an Apache TLP has delegated to PMCs
 
  This is not black and white... The answer can be grey... And everyone is
  human so can make mistakes...
 
  So community, what are you expecting?
 
  - Stephen Connolly
 
  On Thursday, 25 July 2013, wrote:
 
   Author: jdcasey
   Date: Wed Jul 24 23:21:58 2013
   New Revision: 1506778
  
   URL: http://svn.apache.org/r1506778
   Log:
   Adding section on PMC standards of community commitment
  
   Modified:
   maven/site/trunk/content/markdown/project-roles.md
  
   Modified: maven/site/trunk/content/markdown/project-roles.md
   URL:
   http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project
   -roles.md?rev=1506778r1=1506777r2=1506778view=diff
  
   ==
   
   --- maven/site/trunk/content/markdown/project-roles.md (original)
   +++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24
   23:21:58 2013
   @@ -176,6 +176,29 @@ The Project Management Committee has the
* Voting on release artifacts.
* !-- TODO: get the rest of these --
  
   + Standards for Community Commitment
   +
   +In the spirit of supporting the health of our community, Project
   +Management Committee members refrain from actions that subvert the
   +functioning of the committee itself.
   +
   +First, Project Management Committee members should not maintain
   long-running
   +forks of Maven code outside of the project itself. Making significant
   +changes to Maven code outside of the project displays a lack of
   +investment in the community. Additionally, attempting to re-integrate
   +a large number of code changes in bulk overwhelms the ability of
   +volunteers in the community to review (and potentially veto) the
   +changes. This effectively thwarts the policing function of the PMC.
   +
   +Second, Project Management Committee members should not divert work
   +on redesigning, reimplementing, or improving Maven code to
   +alternative projects outside of this community for the purposes of
   +reintroducing them as replacement

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

Stephen, those are great questions. Yet, I think these questions are riding
an assumption that PMC members are solely volunteering at Apache, because
the emphasis (as I interpret your words) is to place the Apache project
first/above other external contributions. Isn't that the heart of this
debate? A person who solely contributes to Apache and no other OS
organizations has no divided loyalties -- they do all their work here. But
what happens when contributions are here and elsewhere? I ask rhetorically,
to solicit answers, of course... and I see where this is going and what
historical processes within Maven are being addressed.


On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 Perhaps we could reframe the question a little then (as people seem to be
 testing hung up on the committed wording)...

 Should the PMC encourage people experimenting on new improvements to Maven
 to do that work at the ASF? And if so, should they then practice what they
 preach, and ensure that any experiments with Maven take place on the ASF
 SCM servers (at least once such experiments become semi-serious or progress
 enough not to cause egg-on-face syndrome)?

 Shoud the PMC promote other Apache projects, or moving non-Apache projects
 to Apache? (Right now, to work on an issue in core and effect the change
 yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
 Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
 fine with half of these at Eclipse and the ther half here... Or maybe
 not... But that is a lot of projects where you need to establish merit and
 perhaps maintain merit just to be able to commit directly (which sometimes
 is the only way to effect the type of cross system changes that some of our
 more obscure bugs may require... GIT makes this less of a requirement, as
 patches on SVN are a PITA, though) )

 These types of questions need resolution as they will, further down the
 road, rise up again and cause wounds... Eg logback vs log4j2 is one that
 simmers at the edge (any time anyone mentioned coloured loggers)

 -Stephen

 On Thursday, 25 July 2013, Paul Benedict wrote:

  I don't think it is possible to force volunteer efforts and/or limit
  development elsewhere. The idea of supporting a project is a vague
 notion.
  I have my opinions too but this language is clearly unenforceable and
  impractical.
 
  Cheers,
  Paul
 
 
  On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg k...@quipsy.de wrote:
 
   As a Maven user I think that everybody who is working on a project
 should
   behave the same. Hence, I would say, PMC members should rather
 certainly
   demonstrate how to live the community rules.
  
   -Ursprüngliche Nachricht-
   Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
   Gesendet: Donnerstag, 25. Juli 2013 15:16
   An: Maven Users List; Maven Developers List
   Betreff: [DISCUSS] Should the Maven PMC be an example of how we want
 the
   Maven Community to behave (was Re: svn commit: r1506778 -
   /maven/site/trunk/content/markdown/project-roles.md)
  
   There are two schools of thought amongst the current members of this
   projects PMC.
  
   Without wanting to deliberately tip my hand and reveal where my opinion
   is, we would like to solicit the opinions if the community that we
 serve.
  
   Please give us your thoughts.
  
   The topic is essentially:
  
   Do you want the members of the Maven PMC to be social leaders of the
  Maven
   community, who's actions demonstrate the best community behaviour?
  
   The alternative is that members of the Maven PMC are here purely to
   complete the legal requirements that an Apache TLP has delegated to
 PMCs
  
   This is not black and white... The answer can be grey... And everyone
 is
   human so can make mistakes...
  
   So community, what are you expecting?
  
   - Stephen Connolly
  
   On Thursday, 25 July 2013, wrote:
  
Author: jdcasey
Date: Wed Jul 24 23:21:58 2013
New Revision: 1506778
   
URL: http://svn.apache.org/r1506778
Log:
Adding section on PMC standards of community commitment
   
Modified:
maven/site/trunk/content/markdown/project-roles.md
   
Modified: maven/site/trunk/content/markdown/project-roles.md
URL:
   
 http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project
-roles.md?rev=1506778r1=1506777r2=1506778view=diff
   
   
 ==

--- maven/site/trunk/content/markdown/project-roles.md (original)
+++ maven/site/trunk/content/markdown/project-roles.md Wed Jul 24
23:21:58 2013
@@ -176,6 +176,29 @@ The Project Management Committee has the
 * Voting on release artifacts.
 * !-- TODO: get the rest of these --
   
+ Standards for Community Commitment
+
+In the spirit of supporting the health of our community, Project
+Management Committee members

What are the current SCM locations for our Maven 2 branches

Hi

I'm setting up builds in a local Jenkins to run RAT on all our release roots.

I've gotten to Maven 2 now and have some problems on where to get it from...

2.0.x seems to be here:
https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/

2.2.x is both here
https://svn.apache.org/repos/asf/maven/maven-2/branches/maven-2.2.x/
and here:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/maven-2.2.x

I couldn't find a GIT-MOVE.txt file in SVN for 2.2.x (like we have for
the other sub projects that have moved to git) and the Jenkins job for
it at builds.apache.org uses the Subversion URL.

Can someone shed som light on this?

-- 
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

On 25 July 2013 22:17, Paul Benedict pbened...@apache.org wrote:

 Stephen, those are great questions. Yet, I think these questions are riding
 an assumption that PMC members are solely volunteering at Apache, because
 the emphasis (as I interpret your words) is to place the Apache project
 first/above other external contributions. Isn't that the heart of this
 debate? A person who solely contributes to Apache and no other OS
 organizations has no divided loyalties -- they do all their work here. But
 what happens when contributions are here and elsewhere?


If they feel they cannot resolve any conflict between their role on the PMC
and any responsibilities the Maven community decide are part and parcel of
that role with their roles in other projects, then quite simply they can
just step down from the PMC and remain a committer. There is no shame in so
doing.

Which brings us back to what does the community expect from its PMC?


 I ask rhetorically,
 to solicit answers, of course... and I see where this is going and what
 historical processes within Maven are being addressed.


 On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

  Perhaps we could reframe the question a little then (as people seem to be
  testing hung up on the committed wording)...
 
  Should the PMC encourage people experimenting on new improvements to
 Maven
  to do that work at the ASF? And if so, should they then practice what
 they
  preach, and ensure that any experiments with Maven take place on the ASF
  SCM servers (at least once such experiments become semi-serious or
 progress
  enough not to cause egg-on-face syndrome)?
 
  Shoud the PMC promote other Apache projects, or moving non-Apache
 projects
  to Apache? (Right now, to work on an issue in core and effect the change
  yourself you may need to establish merit with: Apache Maven, Eclipse
 Sisu,
  Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
  fine with half of these at Eclipse and the ther half here... Or maybe
  not... But that is a lot of projects where you need to establish merit
 and
  perhaps maintain merit just to be able to commit directly (which
 sometimes
  is the only way to effect the type of cross system changes that some of
 our
  more obscure bugs may require... GIT makes this less of a requirement, as
  patches on SVN are a PITA, though) )
 
  These types of questions need resolution as they will, further down the
  road, rise up again and cause wounds... Eg logback vs log4j2 is one that
  simmers at the edge (any time anyone mentioned coloured loggers)
 
  -Stephen
 
  On Thursday, 25 July 2013, Paul Benedict wrote:
 
   I don't think it is possible to force volunteer efforts and/or limit
   development elsewhere. The idea of supporting a project is a vague
  notion.
   I have my opinions too but this language is clearly unenforceable and
   impractical.
  
   Cheers,
   Paul
  
  
   On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg k...@quipsy.de wrote:
  
As a Maven user I think that everybody who is working on a project
  should
behave the same. Hence, I would say, PMC members should rather
  certainly
demonstrate how to live the community rules.
   
-Ursprüngliche Nachricht-
Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Gesendet: Donnerstag, 25. Juli 2013 15:16
An: Maven Users List; Maven Developers List
Betreff: [DISCUSS] Should the Maven PMC be an example of how we want
  the
Maven Community to behave (was Re: svn commit: r1506778 -
/maven/site/trunk/content/markdown/project-roles.md)
   
There are two schools of thought amongst the current members of this
projects PMC.
   
Without wanting to deliberately tip my hand and reveal where my
 opinion
is, we would like to solicit the opinions if the community that we
  serve.
   
Please give us your thoughts.
   
The topic is essentially:
   
Do you want the members of the Maven PMC to be social leaders of the
   Maven
community, who's actions demonstrate the best community behaviour?
   
The alternative is that members of the Maven PMC are here purely to
complete the legal requirements that an Apache TLP has delegated to
  PMCs
   
This is not black and white... The answer can be grey... And everyone
  is
human so can make mistakes...
   
So community, what are you expecting?
   
- Stephen Connolly
   
On Thursday, 25 July 2013, wrote:
   
 Author: jdcasey
 Date: Wed Jul 24 23:21:58 2013
 New Revision: 1506778

 URL: http://svn.apache.org/r1506778
 Log:
 Adding section on PMC standards of community commitment

 Modified:
 maven/site/trunk/content/markdown/project-roles.md

 Modified: maven/site/trunk/content/markdown/project-roles.md
 URL:

  http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Nigel Magnay



 Should the PMC encourage people experimenting on new improvements to Maven
 to do that work at the ASF? And if so, should they then practice what they
 preach, and ensure that any experiments with Maven take place on the ASF
 SCM servers (at least once such experiments become semi-serious or progress
 enough not to cause egg-on-face syndrome)?


That feels to me like swimming entirely against the tide, and a recipe for
irrelevance.

Who, in 2013, *cares* about Apache's SCM? OSS, for just about everyone I
speak to these days runs thus:

1) Is it on Github?
2) If no, fork onto GIthub.

ASF might indeed value community over code, but that doesn't seem to be a
winning strategy any longer, and those changes seem to be trying to
double-down on that strategy.

Perhaps Maven should extricate itself from the ASF. Maybe that's what long
standing forks will do.

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread John Casey


On 7/25/13 4:17 PM, Paul Benedict wrote:

Stephen, those are great questions. Yet, I think these questions are riding
an assumption that PMC members are solely volunteering at Apache, because
the emphasis (as I interpret your words) is to place the Apache project
first/above other external contributions. Isn't that the heart of this
debate? A person who solely contributes to Apache and no other OS
organizations has no divided loyalties -- they do all their work here. But
what happens when contributions are here and elsewhere? I ask rhetorically,
to solicit answers, of course... and I see where this is going and what
historical processes within Maven are being addressed.



I don't think it's about whether you contribute elsewhere or not. It's 
about whether you expect to do a ton of work outside the community here, 
outside the commit logs and the review, in order to avoid the discussion 
and potential for veto.


Working in this way opens the possibility for changing the rules for who 
gets to contribute, especially when code diverges for long periods then 
gets reconciled with a massive rebase.


ASF is supposed to be about more than code. We're supposed to be working 
together on this project. I feel like the above hamstrings that whole 
process.


And note: I'm only suggesting that the PMC - who is supposed to have the 
long-term interests of *this* project at heart - be held to a higher 
standard, to provide an example for the rest of the project. This is not 
saying you're stuck working solely within Maven just because you're on 
the PMC; it's saying that you should promote the health of the community 
by making sure the processes in place work as well as possible.


ASF membership is supposed to be reserved for those who get the Apache 
Way, and I've heard it said that PMC membership should imply ASF 
membership. IMO, working for extended periods outside of the venues for 
our community is not consistent with having the best interests of this 
project in mind.





On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:


Perhaps we could reframe the question a little then (as people seem to be
testing hung up on the committed wording)...

Should the PMC encourage people experimenting on new improvements to Maven
to do that work at the ASF? And if so, should they then practice what they
preach, and ensure that any experiments with Maven take place on the ASF
SCM servers (at least once such experiments become semi-serious or progress
enough not to cause egg-on-face syndrome)?

Shoud the PMC promote other Apache projects, or moving non-Apache projects
to Apache? (Right now, to work on an issue in core and effect the change
yourself you may need to establish merit with: Apache Maven, Eclipse Sisu,
Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
fine with half of these at Eclipse and the ther half here... Or maybe
not... But that is a lot of projects where you need to establish merit and
perhaps maintain merit just to be able to commit directly (which sometimes
is the only way to effect the type of cross system changes that some of our
more obscure bugs may require... GIT makes this less of a requirement, as
patches on SVN are a PITA, though) )

These types of questions need resolution as they will, further down the
road, rise up again and cause wounds... Eg logback vs log4j2 is one that
simmers at the edge (any time anyone mentioned coloured loggers)

-Stephen

On Thursday, 25 July 2013, Paul Benedict wrote:


I don't think it is possible to force volunteer efforts and/or limit
development elsewhere. The idea of supporting a project is a vague

notion.

I have my opinions too but this language is clearly unenforceable and
impractical.

Cheers,
Paul


On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg k...@quipsy.de wrote:


As a Maven user I think that everybody who is working on a project

should

behave the same. Hence, I would say, PMC members should rather

certainly

demonstrate how to live the community rules.

-Ursprüngliche Nachricht-
Von: Stephen Connolly [mailto:stephen.alan.conno...@gmail.com]
Gesendet: Donnerstag, 25. Juli 2013 15:16
An: Maven Users List; Maven Developers List
Betreff: [DISCUSS] Should the Maven PMC be an example of how we want

the

Maven Community to behave (was Re: svn commit: r1506778 -
/maven/site/trunk/content/markdown/project-roles.md)

There are two schools of thought amongst the current members of this
projects PMC.

Without wanting to deliberately tip my hand and reveal where my opinion
is, we would like to solicit the opinions if the community that we

serve.


Please give us your thoughts.

The topic is essentially:

Do you want the members of the Maven PMC to be social leaders of the

Maven

community, who's actions demonstrate the best community behaviour?

The alternative is that members of the Maven PMC are here purely to
complete the legal requirements that an Apache TLP has delegated to

PMCs

Re: svn commit: r1507123 - in /maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install: AbstractInstallMojo.java InstallFileMojo.java InstallMojo.java

On 25 July 2013 21:54,  rfscho...@apache.org wrote:
 Author: rfscholte
 Date: Thu Jul 25 20:54:43 2013
 New Revision: 1507123

 URL: http://svn.apache.org/r1507123
 Log:
 apply generics

 Modified:
 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/AbstractInstallMojo.java
 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallFileMojo.java
 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallMojo.java

 Modified: 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/AbstractInstallMojo.java
 URL: 
 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/AbstractInstallMojo.java?rev=1507123r1=1507122r2=1507123view=diff
 ==
 --- 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/AbstractInstallMojo.java
  (original)
 +++ 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/AbstractInstallMojo.java
  Thu Jul 25 20:54:43 2013
 @@ -19,6 +19,10 @@ package org.apache.maven.plugin.install;
   * under the License.
   */

 +import java.io.File;
 +import java.io.IOException;
 +import java.util.Collection;
 +
  import org.apache.maven.artifact.Artifact;
  import org.apache.maven.artifact.factory.ArtifactFactory;
  import org.apache.maven.artifact.installer.ArtifactInstaller;
 @@ -32,11 +36,6 @@ import org.codehaus.plexus.digest.Digest
  import org.codehaus.plexus.digest.DigesterException;
  import org.codehaus.plexus.util.FileUtils;

 -import java.io.File;
 -import java.io.IOException;
 -import java.util.Collection;
 -import java.util.Iterator;
 -
  /**
   * Common fields for installation mojos.
   *
 @@ -126,7 +125,7 @@ public abstract class AbstractInstallMoj
   *must not be codenull/code.
   * @throws MojoExecutionException If the checksums could not be 
 installed.
   */
 -protected void installChecksums( Artifact artifact, Collection 
 metadataFiles )
 +protected void installChecksums( Artifact artifact, CollectionFile 
 metadataFiles )
  throws MojoExecutionException
  {
  if ( !createChecksum )
 @@ -137,12 +136,12 @@ public abstract class AbstractInstallMoj
  File artifactFile = getLocalRepoFile( artifact );
  installChecksums( artifactFile );

 -Collection metadatas = artifact.getMetadataList();
 +@SuppressWarnings( unchecked )

Why is it safe to ignore the unchecked warning?
This should be documented in an inline comment, e.g.
@SuppressWarnings( unchecked ) // safe because ...

If it's not true that the warning can be safely ignored, then either
leave the warning, or document under what circumstances the code can
fail

 +CollectionArtifactMetadata metadatas = artifact.getMetadataList();
  if ( metadatas != null )
  {
 -for ( Iterator it = metadatas.iterator(); it.hasNext(); )
 +for ( ArtifactMetadata metadata : metadatas )
  {
 -ArtifactMetadata metadata = (ArtifactMetadata) it.next();
  File metadataFile = getLocalRepoFile( metadata );
  metadataFiles.add( metadataFile );
  }
 @@ -155,12 +154,11 @@ public abstract class AbstractInstallMoj
   * @param metadataFiles The collection of metadata files to install 
 checksums for, must not be codenull/code.
   * @throws MojoExecutionException If the checksums could not be 
 installed.
   */
 -protected void installChecksums( Collection metadataFiles )
 +protected void installChecksums( CollectionFile metadataFiles )
  throws MojoExecutionException
  {
 -for ( Iterator it = metadataFiles.iterator(); it.hasNext(); )
 +for ( File metadataFile : metadataFiles )
  {
 -File metadataFile = (File) it.next();
  installChecksums( metadataFile );
  }
  }

 Modified: 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallFileMojo.java
 URL: 
 http://svn.apache.org/viewvc/maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallFileMojo.java?rev=1507123r1=1507122r2=1507123view=diff
 ==
 --- 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallFileMojo.java
  (original)
 +++ 
 maven/plugins/trunk/maven-install-plugin/src/main/java/org/apache/maven/plugin/install/InstallFileMojo.java
  Thu Jul 25 20:54:43 2013
 @@ -153,7 +153,7 @@ public class InstallFileMojo
   * Map that contains the repository layouts.
   */
  @Component( role = ArtifactRepositoryLayout.class )
 -private Map repositoryLayouts;
 +

Re: Issue management and documentation for Apache resources, such as apache-jar-resource-bundle

2013-07-25 Thread Hervé BOUTEMY

I had a look at this issue a few monthes ago

I'd expect http://maven.apache.org/resource/ (like /plugins/) instead of 
http://maven.apache.org/apache-resource-bundles/ .
But I didn't really understand which modules were really useful, and doing 
such a change would require doing a release to really make the new site 
organization effective.

For the Jira creation, MRES? to keep it simple

Regards,

Hervé

Le dimanche 21 juillet 2013 16:01:24 Dennis Lundberg a écrit :
 Hi,
 
 I had a look at, and fixed https://jira.codehaus.org/browse/MRRESOURCES-69
 
 When I first saw the issue I thought, hey this is in the wrong JIRA
 project and went about trying to move it to the correct one. But there
 is no IssueManagement in any of the POMs at
 https://svn.apache.org/viewvc/maven/resources/trunk/
 
 There is a component apache-jar-resource-bundle that has been used
 on a couple of occasions at https://issues.apache.org/jira/browse/MPOM
 but it does feel like the right place for it either. I think we should
 set up a new separate JIRA project for these resource bundles in the
 ASF JIRA instance. Any suggestions for a name for it? I can take it to
 infra once we agree and have come up with a good name.
 
 Another thing is documentation. Currently there is a web site at
 http://maven.apache.org/apache-resource-bundles/ which kind of
 documents a couple of the resource bundles, but not all of them. The
 site (one page only) is currently published using the aggregator POM
 for the resource bundles. There is also a sample project called
 resources-bundles-sample that has a real POM that can be used to try
 out the different resource bundles. There is documentation inside that
 POM which is then duplicated in the site for the aggregator. It would
 be nice if we could have just one copy of the examples... We need to
 get something in place similar to what we have for our parent POMs.
 
 Since there is no JIRA-link from the site there is also no way, except
 by looking in svn, to find out what has happened in a particular
 release.
 
 By the way there is an issue about this at
 https://issues.apache.org/jira/browse/MPOM-28
 
 Thoughts and opinions?

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [VOTE] Release Apache Maven IDEA Plugin version 2.2.1

2013-07-25 Thread Hervé BOUTEMY

+1
thanks for the hard work

Regards,

Hervé

Le mardi 23 juillet 2013 20:23:19 Dennis Lundberg a écrit :
 Hi,
 
 This is the final release of this plugin. After this release it will
 be retired, see separate vote thread for more info on that.
 
 We solved 1 issue:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11135styleName=H
 tmlversion=14478
 
 There are still a couple of issues left in JIRA:
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11135sta
 tus=1
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-008/
 https://repository.apache.org/content/repositories/maven-008/org/apache/mave
 n/plugins/maven-idea-plugin/2.2.1/maven-idea-plugin-2.2.1-source-release.zip
 
 For those interested, the SCM URL can be found in the pom.xml that is
 in the staging repo.
 
 Staging site:
 http://maven.apache.org/plugins-archives/maven-idea-plugin-2.2.1/
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

Agreed. I'll tip my hand and give my opinion: PMC members should have an
Apache first mentality. They are gatekeepers and guardians of their
project. Spinning off critical code to other OSS organizations should be
frowned upon -- it splits the development and wider community into smaller
pieces.

NB: My original response was just criticism of the commitment wording. It's
nice to say what commitments PMC members should have, but if there's no way
to enforce it, it puts into question why the commitments are even expected.
AFAIK, merit at Apache is forever -- you can't have it undone. If someone
loses their Apache first spirit and begins critical development
elsewhere, what can be done about it? Are there any practical recourses? I
don't think there is which is why Maven development has that problem today.



On Thu, Jul 25, 2013 at 4:36 PM, John Casey jdca...@commonjava.org wrote:

 On 7/25/13 4:17 PM, Paul Benedict wrote:

 Stephen, those are great questions. Yet, I think these questions are
 riding
 an assumption that PMC members are solely volunteering at Apache, because
 the emphasis (as I interpret your words) is to place the Apache project
 first/above other external contributions. Isn't that the heart of this
 debate? A person who solely contributes to Apache and no other OS
 organizations has no divided loyalties -- they do all their work here. But
 what happens when contributions are here and elsewhere? I ask
 rhetorically,
 to solicit answers, of course... and I see where this is going and what
 historical processes within Maven are being addressed.



 I don't think it's about whether you contribute elsewhere or not. It's
 about whether you expect to do a ton of work outside the community here,
 outside the commit logs and the review, in order to avoid the discussion
 and potential for veto.

 Working in this way opens the possibility for changing the rules for who
 gets to contribute, especially when code diverges for long periods then
 gets reconciled with a massive rebase.

 ASF is supposed to be about more than code. We're supposed to be working
 together on this project. I feel like the above hamstrings that whole
 process.

 And note: I'm only suggesting that the PMC - who is supposed to have the
 long-term interests of *this* project at heart - be held to a higher
 standard, to provide an example for the rest of the project. This is not
 saying you're stuck working solely within Maven just because you're on the
 PMC; it's saying that you should promote the health of the community by
 making sure the processes in place work as well as possible.

 ASF membership is supposed to be reserved for those who get the Apache
 Way, and I've heard it said that PMC membership should imply ASF
 membership. IMO, working for extended periods outside of the venues for our
 community is not consistent with having the best interests of this project
 in mind.




 On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly 
 stephen.alan.connolly@gmail.**com stephen.alan.conno...@gmail.com
 wrote:

  Perhaps we could reframe the question a little then (as people seem to be
 testing hung up on the committed wording)...

 Should the PMC encourage people experimenting on new improvements to
 Maven
 to do that work at the ASF? And if so, should they then practice what
 they
 preach, and ensure that any experiments with Maven take place on the ASF
 SCM servers (at least once such experiments become semi-serious or
 progress
 enough not to cause egg-on-face syndrome)?

 Shoud the PMC promote other Apache projects, or moving non-Apache
 projects
 to Apache? (Right now, to work on an issue in core and effect the change
 yourself you may need to establish merit with: Apache Maven, Eclipse
 Sisu,
 Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
 fine with half of these at Eclipse and the ther half here... Or maybe
 not... But that is a lot of projects where you need to establish merit
 and
 perhaps maintain merit just to be able to commit directly (which
 sometimes
 is the only way to effect the type of cross system changes that some of
 our
 more obscure bugs may require... GIT makes this less of a requirement, as
 patches on SVN are a PITA, though) )

 These types of questions need resolution as they will, further down the
 road, rise up again and cause wounds... Eg logback vs log4j2 is one that
 simmers at the edge (any time anyone mentioned coloured loggers)

 -Stephen

 On Thursday, 25 July 2013, Paul Benedict wrote:

  I don't think it is possible to force volunteer efforts and/or limit
 development elsewhere. The idea of supporting a project is a vague

 notion.

 I have my opinions too but this language is clearly unenforceable and
 impractical.

 Cheers,
 Paul


 On Thu, Jul 25, 2013 at 9:30 AM, Markus Karg k...@quipsy.de wrote:

  As a Maven user I think that everybody who is working on a project

 should

 behave the same. Hence, I would say, PMC members should rather

 certainly

 demonstrate

Re: [VOTE] Release Apache Maven Model Converter version 2.3

2013-07-25 Thread Hervé BOUTEMY

+1

Regards,

Hervé

Le mardi 23 juillet 2013 21:45:52 Dennis Lundberg a écrit :
 Hi,
 
 This will be the final release of this shared component. After this
 release it will retire from the Apache Maven project and move to the
 Apache Archiva project. See separate vote thread about that.
 
 We solved 6 issues:
 http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11761styleName=H
 tmlversion=14389
 
 There are no issues left in JIRA (except for the one to retire, which
 I'll close later):
 http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11761com
 ponent=13272status=1
 
 Staging repo:
 https://repository.apache.org/content/repositories/maven-010/
 https://repository.apache.org/content/repositories/maven-010/org/apache/mave
 n/shared/maven-model-converter/2.3/maven-model-converter-2.3-source-release.
 zip
 
 Staging site (not synced yet):
 http://maven.apache.org/shared-archives/maven-model-converter-2.3/
 
 Guide to testing staged releases:
 http://maven.apache.org/guides/development/guide-testing-releases.html
 
 Vote open for 72 hours.
 
 [ ] +1
 [ ] +0
 [ ] -1

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

On 25 July 2013 22:34, Nigel Magnay nigel.mag...@gmail.com wrote:

 
 
  Should the PMC encourage people experimenting on new improvements to
 Maven
  to do that work at the ASF? And if so, should they then practice what
 they
  preach, and ensure that any experiments with Maven take place on the ASF
  SCM servers (at least once such experiments become semi-serious or
 progress
  enough not to cause egg-on-face syndrome)?
 
 
 That feels to me like swimming entirely against the tide, and a recipe for
 irrelevance.

 Who, in 2013, *cares* about Apache's SCM? OSS, for just about everyone I
 speak to these days runs thus:

 1) Is it on Github?
 2) If no, fork onto GIthub.

 ASF might indeed value community over code, but that doesn't seem to be a
 winning strategy any longer, and those changes seem to be trying to
 double-down on that strategy.


There is nothing preventing the project from being mirrored onto GitHub,
and in fact the Maven project is mirrored there.

We *legally* need to have the code end up back at ASF if we are to release
it under the legal protections that the ASF provides.

We *legally* are supposed to review aspects of the provenance of the code
that gets released. The more code development that takes place on non ASF
servers, the less we can be sure of.

By having commits and forks at ASF, then each non-ASF set of commits will
be smaller and more likely from a single author which means less work for
reviewing.

Code dumps from a long running fork are thus incompatible with releasing
from the ASF

If you are a YOLO developer, perhaps you don't care about the legal
stuff... your prerogative... I think it is a mistake though.



 Perhaps Maven should extricate itself from the ASF. Maybe that's what long
 standing forks will do.


Perhaps. Perhaps not. This is a different question... and one that also
begs an answer to a different question: what value do users of Maven place
on the legal protections that being released from the ASF provide. There is
also the question of whether the developers value the legal protections.

But at the end of they day there seems to be quite a large cohort of OSS
developers who take a YOLO attitude towards legal stuff[1]... who knows
what experiences they will encounter in the next few years and whether they
will change their opinions in the light of their experiences and whether
they will then see relevance in the ASF.

[1]: There are lots of projects on GitHub that don't even bother to have a
license

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Fred Cooke

So much in-crowd politics and unspoken but apparently well-known material.

Who is the person, who if they were to come across this, would obviously
know they were being talked about anyway?

Where is the, almost certainly short lived, fork of Maven located? A quick
search failed to reveal this.

Such material is best on the table.

Fred.

On Fri, Jul 26, 2013 at 12:07 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 On 25 July 2013 22:34, Nigel Magnay nigel.mag...@gmail.com wrote:

  
  
   Should the PMC encourage people experimenting on new improvements to
  Maven
   to do that work at the ASF? And if so, should they then practice what
  they
   preach, and ensure that any experiments with Maven take place on the
 ASF
   SCM servers (at least once such experiments become semi-serious or
  progress
   enough not to cause egg-on-face syndrome)?
  
  
  That feels to me like swimming entirely against the tide, and a recipe
 for
  irrelevance.
 
  Who, in 2013, *cares* about Apache's SCM? OSS, for just about everyone I
  speak to these days runs thus:
 
  1) Is it on Github?
  2) If no, fork onto GIthub.
 
  ASF might indeed value community over code, but that doesn't seem to
 be a
  winning strategy any longer, and those changes seem to be trying to
  double-down on that strategy.
 

 There is nothing preventing the project from being mirrored onto GitHub,
 and in fact the Maven project is mirrored there.

 We *legally* need to have the code end up back at ASF if we are to release
 it under the legal protections that the ASF provides.

 We *legally* are supposed to review aspects of the provenance of the code
 that gets released. The more code development that takes place on non ASF
 servers, the less we can be sure of.

 By having commits and forks at ASF, then each non-ASF set of commits will
 be smaller and more likely from a single author which means less work for
 reviewing.

 Code dumps from a long running fork are thus incompatible with releasing
 from the ASF

 If you are a YOLO developer, perhaps you don't care about the legal
 stuff... your prerogative... I think it is a mistake though.


 
  Perhaps Maven should extricate itself from the ASF. Maybe that's what
 long
  standing forks will do.
 

 Perhaps. Perhaps not. This is a different question... and one that also
 begs an answer to a different question: what value do users of Maven place
 on the legal protections that being released from the ASF provide. There is
 also the question of whether the developers value the legal protections.

 But at the end of they day there seems to be quite a large cohort of OSS
 developers who take a YOLO attitude towards legal stuff[1]... who knows
 what experiences they will encounter in the next few years and whether they
 will change their opinions in the light of their experiences and whether
 they will then see relevance in the ASF.

 [1]: There are lots of projects on GitHub that don't even bother to have a
 license

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

On 25 July 2013 23:15, Fred Cooke fred.co...@gmail.com wrote:

 So much in-crowd politics and unspoken but apparently well-known material.

 Who is the person, who if they were to come across this, would obviously
 know they were being talked about anyway?


I would rather we not focus on specific people. This should be a question
that is isolated from any specific person. Often times when there is a
specific person in mind people can have biases both for that person or
against that person which can colour their views of the question at hand.



 Where is the, almost certainly short lived, fork of Maven located? A quick
 search failed to reveal this.


There is at least one Maven Committer who has been maintaining a fork of
Maven for perhaps the greater part of a year. There is nothing wrong with
committers maintaining their own private forks. If they intend on bringing
the work back to the Maven project, then the best way to achieve that is in
smaller parts and not as one big code drop at the end.

The question is whether the community sees this as against the spirit of
what it means to be part of the PMC.

We could pick one specific individual as a test case but I don't think
that would be productive. Any such individual is likely to bring a lot of
other baggage with them and could therefore confuse the results of such a
test case


 Such material is best on the table.


I hope we don't have to devolve to specifics about specific individuals.



 Fred.

 On Fri, Jul 26, 2013 at 12:07 AM, Stephen Connolly 
 stephen.alan.conno...@gmail.com wrote:

  On 25 July 2013 22:34, Nigel Magnay nigel.mag...@gmail.com wrote:
 
   
   
Should the PMC encourage people experimenting on new improvements to
   Maven
to do that work at the ASF? And if so, should they then practice what
   they
preach, and ensure that any experiments with Maven take place on the
  ASF
SCM servers (at least once such experiments become semi-serious or
   progress
enough not to cause egg-on-face syndrome)?
   
   
   That feels to me like swimming entirely against the tide, and a recipe
  for
   irrelevance.
  
   Who, in 2013, *cares* about Apache's SCM? OSS, for just about everyone
 I
   speak to these days runs thus:
  
   1) Is it on Github?
   2) If no, fork onto GIthub.
  
   ASF might indeed value community over code, but that doesn't seem to
  be a
   winning strategy any longer, and those changes seem to be trying to
   double-down on that strategy.
  
 
  There is nothing preventing the project from being mirrored onto GitHub,
  and in fact the Maven project is mirrored there.
 
  We *legally* need to have the code end up back at ASF if we are to
 release
  it under the legal protections that the ASF provides.
 
  We *legally* are supposed to review aspects of the provenance of the code
  that gets released. The more code development that takes place on non ASF
  servers, the less we can be sure of.
 
  By having commits and forks at ASF, then each non-ASF set of commits will
  be smaller and more likely from a single author which means less work for
  reviewing.
 
  Code dumps from a long running fork are thus incompatible with releasing
  from the ASF
 
  If you are a YOLO developer, perhaps you don't care about the legal
  stuff... your prerogative... I think it is a mistake though.
 
 
  
   Perhaps Maven should extricate itself from the ASF. Maybe that's what
  long
   standing forks will do.
  
 
  Perhaps. Perhaps not. This is a different question... and one that also
  begs an answer to a different question: what value do users of Maven
 place
  on the legal protections that being released from the ASF provide. There
 is
  also the question of whether the developers value the legal protections.
 
  But at the end of they day there seems to be quite a large cohort of OSS
  developers who take a YOLO attitude towards legal stuff[1]... who knows
  what experiences they will encounter in the next few years and whether
 they
  will change their opinions in the light of their experiences and whether
  they will then see relevance in the ASF.
 
  [1]: There are lots of projects on GitHub that don't even bother to have
 a
  license

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Fred Cooke

It would appear to me to be an evolution from the implicit nature of this
conversation thus far, but whatever, I couldn't care less. I just find
talking about it without talking about it in poor taste.

About the fork, though, I'm interested. I'm interested in why it's
maintained and how it differs. I'm interested because I intend to fork it
myself to fix things which would break others which I know won't change
upstream (site and release stuff). Perhaps someone already fixed what I
consider broken and others, perhaps, do not consider broken. Email me
privately if need be.

If the fork is just a branch (or set thereof), and not promoted as a fork
(in a social sense), then is there really any harm? Is it being viewed as a
loss of potential work done? Open source is open for a reason.

Fred.

On Fri, Jul 26, 2013 at 12:28 AM, Stephen Connolly 
stephen.alan.conno...@gmail.com wrote:

 On 25 July 2013 23:15, Fred Cooke fred.co...@gmail.com wrote:

  So much in-crowd politics and unspoken but apparently well-known
 material.
 
  Who is the person, who if they were to come across this, would obviously
  know they were being talked about anyway?
 

 I would rather we not focus on specific people. This should be a question
 that is isolated from any specific person. Often times when there is a
 specific person in mind people can have biases both for that person or
 against that person which can colour their views of the question at hand.


 
  Where is the, almost certainly short lived, fork of Maven located? A
 quick
  search failed to reveal this.
 

 There is at least one Maven Committer who has been maintaining a fork of
 Maven for perhaps the greater part of a year. There is nothing wrong with
 committers maintaining their own private forks. If they intend on bringing
 the work back to the Maven project, then the best way to achieve that is in
 smaller parts and not as one big code drop at the end.

 The question is whether the community sees this as against the spirit of
 what it means to be part of the PMC.

 We could pick one specific individual as a test case but I don't think
 that would be productive. Any such individual is likely to bring a lot of
 other baggage with them and could therefore confuse the results of such a
 test case


  Such material is best on the table.
 

 I hope we don't have to devolve to specifics about specific individuals.


 
  Fred.
 
  On Fri, Jul 26, 2013 at 12:07 AM, Stephen Connolly 
  stephen.alan.conno...@gmail.com wrote:
 
   On 25 July 2013 22:34, Nigel Magnay nigel.mag...@gmail.com wrote:
  


 Should the PMC encourage people experimenting on new improvements
 to
Maven
 to do that work at the ASF? And if so, should they then practice
 what
they
 preach, and ensure that any experiments with Maven take place on
 the
   ASF
 SCM servers (at least once such experiments become semi-serious or
progress
 enough not to cause egg-on-face syndrome)?


That feels to me like swimming entirely against the tide, and a
 recipe
   for
irrelevance.
   
Who, in 2013, *cares* about Apache's SCM? OSS, for just about
 everyone
  I
speak to these days runs thus:
   
1) Is it on Github?
2) If no, fork onto GIthub.
   
ASF might indeed value community over code, but that doesn't seem
 to
   be a
winning strategy any longer, and those changes seem to be trying to
double-down on that strategy.
   
  
   There is nothing preventing the project from being mirrored onto
 GitHub,
   and in fact the Maven project is mirrored there.
  
   We *legally* need to have the code end up back at ASF if we are to
  release
   it under the legal protections that the ASF provides.
  
   We *legally* are supposed to review aspects of the provenance of the
 code
   that gets released. The more code development that takes place on non
 ASF
   servers, the less we can be sure of.
  
   By having commits and forks at ASF, then each non-ASF set of commits
 will
   be smaller and more likely from a single author which means less work
 for
   reviewing.
  
   Code dumps from a long running fork are thus incompatible with
 releasing
   from the ASF
  
   If you are a YOLO developer, perhaps you don't care about the legal
   stuff... your prerogative... I think it is a mistake though.
  
  
   
Perhaps Maven should extricate itself from the ASF. Maybe that's what
   long
standing forks will do.
   
  
   Perhaps. Perhaps not. This is a different question... and one that also
   begs an answer to a different question: what value do users of Maven
  place
   on the legal protections that being released from the ASF provide.
 There
  is
   also the question of whether the developers value the legal
 protections.
  
   But at the end of they day there seems to be quite a large cohort of
 OSS
   developers who take a YOLO attitude towards legal stuff[1]... who knows
   what experiences they will encounter in the next few years and

Re: What are the current SCM locations for our Maven 2 branches

2013-07-25 Thread Olivier Lamy

2013/7/26 Dennis Lundberg denn...@apache.org:
 Hi

 I'm setting up builds in a local Jenkins to run RAT on all our release roots.

 I've gotten to Maven 2 now and have some problems on where to get it from...

 2.0.x seems to be here:
 https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/

 2.2.x is both here
 https://svn.apache.org/repos/asf/maven/maven-2/branches/maven-2.2.x/
 and here:
 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/maven-2.2.x

 I couldn't find a GIT-MOVE.txt file in SVN for 2.2.x (like we have for
 the other sub projects that have moved to git) and the Jenkins job for
 it at builds.apache.org uses the Subversion URL.

 Can someone shed som light on this?

should be on git now.
I fixed the jenkins build.



 --
 Dennis Lundberg

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
Olivier Lamy
Ecetera: http://ecetera.com.au
http://twitter.com/olamy | http://linkedin.com/in/olamy

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Brian Fox


 There is at least one Maven Committer who has been maintaining a fork of
 Maven for perhaps the greater part of a year.

Is it really a fork? Or is it a superset? I think people throw around
fork but is that really true?

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: Maven 3.1.0 class loading error with Swagger Maven Plugin

2013-07-25 Thread Stuart McCulloch


On 23 Jul 2013, at 05:47, Brett Porter wrote:

 
 On 18/07/2013, at 6:36 PM, Stuart McCulloch mccu...@gmail.com wrote:
 
 On 18 Jul 2013, at 05:41, Brett Porter br...@apache.org wrote:
 
 Hi,
 
 I've got a regression here using the Swagger Maven Plugin [1] that looks 
 different to the Aether one. Before I go poking around further, I was 
 wondering if anyone can tell me if it's a regression on the Maven (and 
 dependencies) end, or something expected to be updated in the plugin?
 
 The converter code (part of the plexus adapter layer) was clean-roomed when 
 it moved to eclipse and this particular legacy constructor was missed.
 
 I'll fix this and stage a container update - note that the call to register 
 the realm converter isn't strictly necessary and could also be removed from 
 the plugin.
 
 Thanks for the tip - applied to the plugin in question in case anyone else is 
 using it: https://github.com/kongchen/swagger-maven-plugin/pull/15

I've staged a container build with this fix, links available in latest JIRA 
comment:

https://jira.codehaus.org/browse/MNG-5495#comment-329526

It's late here, so will let people give it a spin and plan to push it to 
central at the weekend unless I hear otherwise.

Thanks for reporting this.

--
Cheers, Stuart

 - Brett
 
 --
 Brett Porter
 br...@apache.org
 http://brettporter.wordpress.com/
 http://au.linkedin.com/in/brettporter
 http://twitter.com/brettporter


-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

On 25 July 2013 22:55, Paul Benedict pbened...@apache.org wrote:
 Agreed. I'll tip my hand and give my opinion: PMC members should have an
 Apache first mentality. They are gatekeepers and guardians of their
 project. Spinning off critical code to other OSS organizations should be
 frowned upon -- it splits the development and wider community into smaller
 pieces.

+1

 NB: My original response was just criticism of the commitment wording. It's
 nice to say what commitments PMC members should have, but if there's no way
 to enforce it, it puts into question why the commitments are even expected.
 AFAIK, merit at Apache is forever -- you can't have it undone. If someone
 loses their Apache first spirit and begins critical development
 elsewhere, what can be done about it? Are there any practical recourses? I
 don't think there is which is why Maven development has that problem today.

Surely the PMC can vote to remove individuals from the PMC if necessary?

If the PMC as a whole agrees to a particular code of conduct, then
anyone who does not conform should be politely reminded (on the
private@ list) of their responsibilities. Only if the non-conforming
behaviour persists should further action be taken.



 On Thu, Jul 25, 2013 at 4:36 PM, John Casey jdca...@commonjava.org wrote:

 On 7/25/13 4:17 PM, Paul Benedict wrote:

 Stephen, those are great questions. Yet, I think these questions are
 riding
 an assumption that PMC members are solely volunteering at Apache, because
 the emphasis (as I interpret your words) is to place the Apache project
 first/above other external contributions. Isn't that the heart of this
 debate? A person who solely contributes to Apache and no other OS
 organizations has no divided loyalties -- they do all their work here. But
 what happens when contributions are here and elsewhere? I ask
 rhetorically,
 to solicit answers, of course... and I see where this is going and what
 historical processes within Maven are being addressed.



 I don't think it's about whether you contribute elsewhere or not. It's
 about whether you expect to do a ton of work outside the community here,
 outside the commit logs and the review, in order to avoid the discussion
 and potential for veto.

 Working in this way opens the possibility for changing the rules for who
 gets to contribute, especially when code diverges for long periods then
 gets reconciled with a massive rebase.

 ASF is supposed to be about more than code. We're supposed to be working
 together on this project. I feel like the above hamstrings that whole
 process.

 And note: I'm only suggesting that the PMC - who is supposed to have the
 long-term interests of *this* project at heart - be held to a higher
 standard, to provide an example for the rest of the project. This is not
 saying you're stuck working solely within Maven just because you're on the
 PMC; it's saying that you should promote the health of the community by
 making sure the processes in place work as well as possible.

 ASF membership is supposed to be reserved for those who get the Apache
 Way, and I've heard it said that PMC membership should imply ASF
 membership. IMO, working for extended periods outside of the venues for our
 community is not consistent with having the best interests of this project
 in mind.




 On Thu, Jul 25, 2013 at 4:05 PM, Stephen Connolly 
 stephen.alan.connolly@gmail.**com stephen.alan.conno...@gmail.com
 wrote:

  Perhaps we could reframe the question a little then (as people seem to be
 testing hung up on the committed wording)...

 Should the PMC encourage people experimenting on new improvements to
 Maven
 to do that work at the ASF? And if so, should they then practice what
 they
 preach, and ensure that any experiments with Maven take place on the ASF
 SCM servers (at least once such experiments become semi-serious or
 progress
 enough not to cause egg-on-face syndrome)?

 Shoud the PMC promote other Apache projects, or moving non-Apache
 projects
 to Apache? (Right now, to work on an issue in core and effect the change
 yourself you may need to establish merit with: Apache Maven, Eclipse
 Sisu,
 Eclipse Aether, Plexus, Apache Commons, Classworlds, etc. Now it may be
 fine with half of these at Eclipse and the ther half here... Or maybe
 not... But that is a lot of projects where you need to establish merit
 and
 perhaps maintain merit just to be able to commit directly (which
 sometimes
 is the only way to effect the type of cross system changes that some of
 our
 more obscure bugs may require... GIT makes this less of a requirement, as
 patches on SVN are a PITA, though) )

 These types of questions need resolution as they will, further down the
 road, rise up again and cause wounds... Eg logback vs log4j2 is one that
 simmers at the edge (any time anyone mentioned coloured loggers)

 -Stephen

 On Thursday, 25 July 2013, Paul Benedict wrote:

  I don't think it is possible to force volunteer efforts and/or limit
 development

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Wayne Fay

 AFAIK, merit at Apache is forever -- you can't have it undone. If someone
 loses their Apache first spirit and begins critical development
 elsewhere, what can be done about it? Are there any practical recourses? I
 don't think there is which is why Maven development has that problem today.

 Surely the PMC can vote to remove individuals from the PMC if necessary?

They *can* but it rarely occurs for a whole host of reasons...

Wayne

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: What are the current SCM locations for our Maven 2 branches

On Fri, Jul 26, 2013 at 1:06 AM, Olivier Lamy ol...@apache.org wrote:
 2013/7/26 Dennis Lundberg denn...@apache.org:
 Hi

 I'm setting up builds in a local Jenkins to run RAT on all our release roots.

 I've gotten to Maven 2 now and have some problems on where to get it from...

 2.0.x seems to be here:
 https://svn.apache.org/repos/asf/maven/components/branches/maven-2.0.x/

 2.2.x is both here
 https://svn.apache.org/repos/asf/maven/maven-2/branches/maven-2.2.x/
 and here:
 https://git-wip-us.apache.org/repos/asf?p=maven.git;a=shortlog;h=refs/heads/maven-2.2.x

 I couldn't find a GIT-MOVE.txt file in SVN for 2.2.x (like we have for
 the other sub projects that have moved to git) and the Jenkins job for
 it at builds.apache.org uses the Subversion URL.

 Can someone shed som light on this?

 should be on git now.
 I fixed the jenkins build.

Thanks for fixing that Olivier!

The SCM URLs in the pom.xml also needs updating.
What does a git URL look like, if you are using a branch?



 --
 Dennis Lundberg

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




 --
 Olivier Lamy
 Ecetera: http://ecetera.com.au
 http://twitter.com/olamy | http://linkedin.com/in/olamy

 -
 To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
 For additional commands, e-mail: dev-h...@maven.apache.org




-- 
Dennis Lundberg

-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)

2013-07-25 Thread Chris Graham

On Thu, Jul 25, 2013 at 11:16 PM, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:

There are two schools of thought amongst the current members of this
projects PMC.

Are they mutually exclusive?

From my (limited [so I could be way off here]) understanding of Apache,
don't you only get to be on the PMC for having demonstrated the correct
community spirit and sufficient commitment 'to the cause' (as it were)?

And like many real world jobs, when you 'step up' you often gain/get
thrusted upon you more responsibility; it's just a part of the job.

I understand why the Apache Foundation has the legal requirements that it
does. It also needs people to monitor implement them. That appears to fall
upon the PMC.

It seems to me that for someone to get to be on the PMC to start with they
have demonstrated sufficient community spirit and commitment to the project.

So as you said, it's not black and white. :-) I'm happy to see it as both.

Personally, I prefer to lead by example. But you can still do that whilst
maintining the legal requirements.

-Chris

Without wanting to deliberately tip my hand and reveal where my opinion is,
we would like to solicit the opinions if the community that we serve.

Please give us your thoughts.

The topic is essentially:

Do you want the members of the Maven PMC to be social leaders of the Maven
community, who's actions demonstrate the best community behaviour?

The alternative is that members of the Maven PMC are here purely to
complete the legal requirements that an Apache TLP has delegated to PMCs

This is not black and white... The answer can be grey... And everyone is
human so can make mistakes...

So community, what are you expecting?

- Stephen Connolly

On Thursday, 25 July 2013, wrote:

Author: jdcasey
Date: Wed Jul 24 23:21:58 2013
New Revision: 1506778

URL: http://svn.apache.org/r1506778
Log:
Adding section on PMC standards of community commitment

Modified:
maven/site/trunk/content/markdown/project-roles.md

Modified: maven/site/trunk/content/markdown/project-roles.md
URL:

http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1506778r1=1506777r2=1506778view=diff

For various legal reasons, there are certain things that the Apache

--
Sent from my phone

Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)