Re: Donay

[Olivier Lamy]

2013/6/29 Robert Scholte :
> Hi,
>
> recently I noticed a new thing at the Jira of Codehaus: Donay
> It is saying "Facing this issue? Let the Developers help you out."
>
> Here Donay explains how it works:
> https://secure.donay.com/site/how-it-works
>
> Has this been shared with the community?
AFAIK nope.

> Does anybody have experience with this?
No.

>
> IIRC we had a similar situation with http://www.freedomsponsors.org/ and
> we've removed their comments if they were actively busy with crowdfunding.
Maybe is it possible to remove it per project? (you can probably ask
in HAUS jira ?)

>
>
> Robert
>
> -
> 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: [VOTE] Release Maven Enforcer version 1.3 (take 2)

[sebb]

On 29 June 2013 11:47, Robert Scholte  wrote:
> Hi Sebb,
>
> none of these files will end up in Maven Central, they are all used for
> tests.

However, they do end up in the source release which is published via
the ASF mirrors.
It's vital that all released source files have the appropriate header.

> For me that's not enough reason to cancel the vote.
>
> thanks,
>
> Robert
>
> Op Thu, 27 Jun 2013 12:26:03 +0200 schreef sebb :
>
>
>> On 25 June 2013 21:23, Robert Scholte  wrote:
>>>
>>> Hi,
>>>
>>> We solved 15 issues:
>>>
>>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=19011
>>>
>>> There are still a couple of issues left in JIRA:
>>>
>>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11530&status=1
>>>
>>> Staging repo:
>>> https://repository.apache.org/content/repositories/maven-070/
>>>
>>> https://repository.apache.org/content/repositories/maven-070/org/apache/maven/enforcer/enforcer/1.3/enforcer-1.3-source-release.zip
>>>
>>> Staging site:
>>> http://maven.apache.org/enforcer-archives/enforcer-LATEST/
>>>
>>> Guide to testing staged releases:
>>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>>
>>> Vote open for 72 hours.
>>>
>>> [ ] +1
>>> [ ] +0
>>> [X] -1
>>
>>
>> There are lots of files in the source archive that don't have AL headers:
>>
>> enforcer-1.3/DEPENDENCIES
>> enforcer-1.3/enforcer-api/src/custom-rule-sample/pom.xml
>>
>> enforcer-1.3/enforcer-api/src/custom-rule-sample/src/main/java/org/apache/maven/enforcer/rule/MyCustomRule.java
>> enforcer-1.3/enforcer-api/src/custom-rule-sample/src/usage-pom.xml
>> enforcer-1.3/enforcer-api/src/custom-rule-sample/usage-pom.xml
>> enforcer-1.3/enforcer-api/src/main/assembly/custom-rule-sample.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/no-repositories/child/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/no-repositories/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-plugin-repositories/child/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-plugin-repositories/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-repositories/child/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-repositories/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-plugin-repositories/child/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-plugin-repositories/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-repositories/child/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-repositories/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/checkPluginPropertyVersion/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/checkPluginVersionProfile/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/getPomRecursively/b/c/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/getPomRecursively/b/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/getPomRecursively/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/parentExpression/child/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/parentExpression/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/parentRelativePathDirectory/parent/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/parentRelativePathDirectory/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/parentRelativePath/parent/pom.xml
>>
>> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/parentRelativePath/pom.xml
>>
>> enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer126_maven-plugin-1.0.pom
>>
>> enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer128_api-1.4.0.pom
>>
>> enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer128_api-1.5.0.pom
>>
>> enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer128_api-1.6.0.pom
>>
>> enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer128_classic-0.9.9.pom
>>
>> enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer134_model-1.0-20130423.042904-7222.pom
>>
>> enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer134_model-1.0-20130423.044324-5638.pom
>>
>> enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer134_modelbuilder-1.0-SNAPSHOT.pom
>>
>> enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer134_project-1.0-SNAPSHOT.pom
>>
>> enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_archiver-2.1.1.pom
>>

Release process updates (try 2)

[sebb]

The mission of the ASF is to release software as source, and to ensure
that the released source is available under the Apache Licence.

Before a release can be approved it must be voted on by the PMC.
The review process needs to establish that the proposed source release
meets those aims.

It's all but impossible for reviewers to examine every single file in
a source archive to determine if it meets the criteria.

However, PMCs are also required to check what is added to the SCM
(SVN/Git) to make sure it meets the required license criteria.
This is done on an ongoing basis as part of reviewing check-ins and
accepting new contributions.

So provided that all the files in the source release are also present
in SCM, the PMC can be reasonably sure that the source release meets
the ASF criteria.

Effectively the SCM can be viewed as a database of pre-approved files.

Without having the SCM as a database of validated files, there are far
too many files in the average source archive to check individually.
And how would one check their provenance? The obvious way is to
compare them with the entries in SCM.

Therefore, I contend that a release vote does not make sense without
a unique reference to the source files that were used to create the release.

In the case of SVN, since tags are not guaranteed immutable, the vote
e-mail also
needs the revision. The revision alone is not sufficient, because the
ASF SVN is shared.

Now whether every reviewer actually checks the source archive against SCM
is another matter.

But if the required SCM information is not present, it would be
difficult to argue that the RM had provided sufficient information for
a proper review to take place. In which case the vote cannot be
considered valid.

The vote thread needs to provide all the information that is needed to
properly review the release candidate, otherwise IMO it is not a valid
vote.
This is needed both at the time of the vote, and for historic reasons
so the context of the vote is properly recorded.

Please do not obscure this thread with discussions of the release
plugin or tags or merits of Git/SVN.
Such technical aspects belong in separate threads.
They obviously important to the process, but not the vote, which is
about the result.

Reminder: all this thread is just about is adding the following lines
to vote e-mails:

SVN Tag:
https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
(r1496317)

or whatever the equivalent is for Git (or any other SCM that may be in
use at the time).

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

Re: Release process updates (try 2)

[Fred Cooke]

For Git the only thing that is needed is the unique 40 character hash such
as this:

FreeAir:youtube-dl fred$ git rev-parse HEAD
48bfb5f2387ab47e1973d9db0782a9af66ffc4e6

It's just sloppy not to do this; if a quality release process is required,
so is the SVN rev number. If "good enough" is OK, then it can be omitted
because you can, most of the time, just guess. Guessing = mistakes, though.

Fred.

On Sun, Jun 30, 2013 at 8:20 PM, sebb  wrote:

> The mission of the ASF is to release software as source, and to ensure
> that the released source is available under the Apache Licence.
>
> Before a release can be approved it must be voted on by the PMC.
> The review process needs to establish that the proposed source release
> meets those aims.
>
> It's all but impossible for reviewers to examine every single file in
> a source archive to determine if it meets the criteria.
>
> However, PMCs are also required to check what is added to the SCM
> (SVN/Git) to make sure it meets the required license criteria.
> This is done on an ongoing basis as part of reviewing check-ins and
> accepting new contributions.
>
> So provided that all the files in the source release are also present
> in SCM, the PMC can be reasonably sure that the source release meets
> the ASF criteria.
>
> Effectively the SCM can be viewed as a database of pre-approved files.
>
> Without having the SCM as a database of validated files, there are far
> too many files in the average source archive to check individually.
> And how would one check their provenance? The obvious way is to
> compare them with the entries in SCM.
>
> Therefore, I contend that a release vote does not make sense without
> a unique reference to the source files that were used to create the
> release.
>
> In the case of SVN, since tags are not guaranteed immutable, the vote
> e-mail also
> needs the revision. The revision alone is not sufficient, because the
> ASF SVN is shared.
>
> Now whether every reviewer actually checks the source archive against SCM
> is another matter.
>
> But if the required SCM information is not present, it would be
> difficult to argue that the RM had provided sufficient information for
> a proper review to take place. In which case the vote cannot be
> considered valid.
>
> The vote thread needs to provide all the information that is needed to
> properly review the release candidate, otherwise IMO it is not a valid
> vote.
> This is needed both at the time of the vote, and for historic reasons
> so the context of the vote is properly recorded.
>
> Please do not obscure this thread with discussions of the release
> plugin or tags or merits of Git/SVN.
> Such technical aspects belong in separate threads.
> They obviously important to the process, but not the vote, which is
> about the result.
>
> Reminder: all this thread is just about is adding the following lines
> to vote e-mails:
>
> SVN Tag:
>
> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
> (r1496317)
>
> or whatever the equivalent is for Git (or any other SCM that may be in
> use at the time).
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>

[VOTE] Apache 3.1.0

[Jason van Zyl]

Here are the release bits for 3.1.0:

Release notes:
https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967

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

Staged distribution:
https://repository.apache.org/content/repositories/maven-084/org/apache/maven/apache-maven/3.1.0/

Staged Site:
http://maven.apache.org/ref/3.1.0

Thanks,

Jason

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

There's no sense in being precise when you don't even know what you're talking 
about.

 -- John von Neumann

Re: Maven 3.1.0-beta-1

[Dennis Lundberg]

Hi

I see this as well in our corporate aggregator POM that builds everything.
This 124 module build succeeds with Maven 3.0.5, but fails with
java.lang.OutOfMemoryError: PermGen space
after 108 modules when using Maven 3.1.0-alpha-1.

Sorry but I can't share the project.
Are there any free tools that I can use to provide a permgen dump?



On Wed, Jun 26, 2013 at 2:23 PM, Jörg Schaible
wrote:

> Hi Jason,
>
> Jason van Zyl wrote:
>
> > Doesn't see to be a whole lot of activity around the 3.1.0-alpha-1 so I
> > plan to cut the 3.1.0-beta-1 this weekend if there are no objections.
>
> Apart from the reported bogus build with snapshots (MNG-5207) it seems M31
> has a major problem with PermGen space leakage.
>
> We have currently a build that contains 337 projects. With M221 I can build
> all of it in one run in ~11 minutes.
>
> With M305 the build runs faster, but I have to continue it two times with
> "-
> rf" option, because it runs out of PermGen space.
>
> With M31a the leakage is really worse. The build stops because of PermGen
> space 4 times, where I have to continue manually again.
>
> All plugins are locked down, so it has to be related with Maven core.
> MAVEN_OPTS is "-Xmx1g -XX:MaxPermSize=192m" and I am running "mvn clean
> install [-rf ]".
>
> Thanks,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
>


-- 
Dennis Lundberg

Re: Release process updates (try 2)

[Gary Gregory]

Fine with me. Thanks for the explanation sebb.

Gary

On Jun 30, 2013, at 14:20, sebb  wrote:

> The mission of the ASF is to release software as source, and to ensure
> that the released source is available under the Apache Licence.
>
> Before a release can be approved it must be voted on by the PMC.
> The review process needs to establish that the proposed source release
> meets those aims.
>
> It's all but impossible for reviewers to examine every single file in
> a source archive to determine if it meets the criteria.
>
> However, PMCs are also required to check what is added to the SCM
> (SVN/Git) to make sure it meets the required license criteria.
> This is done on an ongoing basis as part of reviewing check-ins and
> accepting new contributions.
>
> So provided that all the files in the source release are also present
> in SCM, the PMC can be reasonably sure that the source release meets
> the ASF criteria.
>
> Effectively the SCM can be viewed as a database of pre-approved files.
>
> Without having the SCM as a database of validated files, there are far
> too many files in the average source archive to check individually.
> And how would one check their provenance? The obvious way is to
> compare them with the entries in SCM.
>
> Therefore, I contend that a release vote does not make sense without
> a unique reference to the source files that were used to create the release.
>
> In the case of SVN, since tags are not guaranteed immutable, the vote
> e-mail also
> needs the revision. The revision alone is not sufficient, because the
> ASF SVN is shared.
>
> Now whether every reviewer actually checks the source archive against SCM
> is another matter.
>
> But if the required SCM information is not present, it would be
> difficult to argue that the RM had provided sufficient information for
> a proper review to take place. In which case the vote cannot be
> considered valid.
>
> The vote thread needs to provide all the information that is needed to
> properly review the release candidate, otherwise IMO it is not a valid
> vote.
> This is needed both at the time of the vote, and for historic reasons
> so the context of the vote is properly recorded.
>
> Please do not obscure this thread with discussions of the release
> plugin or tags or merits of Git/SVN.
> Such technical aspects belong in separate threads.
> They obviously important to the process, but not the vote, which is
> about the result.
>
> Reminder: all this thread is just about is adding the following lines
> to vote e-mails:
>
> SVN Tag:
> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
> (r1496317)
>
> or whatever the equivalent is for Git (or any other SCM that may be in
> use at the time).
>
> -
> 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] Apache 3.1.0

[Mirko Friedenhagen]

+1 (non-binding) tested with some projects.
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/


On Sun, Jun 30, 2013 at 9:00 PM, Jason van Zyl  wrote:
> Here are the release bits for 3.1.0:
>
> Release notes:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-084/
>
> Staged distribution:
> https://repository.apache.org/content/repositories/maven-084/org/apache/maven/apache-maven/3.1.0/
>
> Staged Site:
> http://maven.apache.org/ref/3.1.0
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> There's no sense in being precise when you don't even know what you're 
> talking about.
>
>  -- John von Neumann
>
>
>
>
>

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

Re: [VOTE] Apache 3.1.0

[Mirko Friedenhagen]

So probably this is:
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=commit;h=893ca28a1da9d5f51ac03827af98bb730128f9f2
:-)
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/


On Sun, Jun 30, 2013 at 9:00 PM, Jason van Zyl  wrote:
> Here are the release bits for 3.1.0:
>
> Release notes:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-084/
>
> Staged distribution:
> https://repository.apache.org/content/repositories/maven-084/org/apache/maven/apache-maven/3.1.0/
>
> Staged Site:
> http://maven.apache.org/ref/3.1.0
>
> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> There's no sense in being precise when you don't even know what you're 
> talking about.
>
>  -- John von Neumann
>
>
>
>
>

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

Re: [VOTE] Apache 3.1.0

[sebb]

On 30 June 2013 20:00, Jason van Zyl  wrote:
> Here are the release bits for 3.1.0:
>
> Release notes:
> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>
> Staging repository:
> https://repository.apache.org/content/repositories/maven-084/
>
> Staged distribution:
> https://repository.apache.org/content/repositories/maven-084/org/apache/maven/apache-maven/3.1.0/
>
> Staged Site:
> http://maven.apache.org/ref/3.1.0

Where is the link to the KEYS file (for checking sigs)?

Also link to unique file source set in SCM? (for checking source file
provenance)

-1 (non-binding) without these.

> Thanks,
>
> Jason
>
> --
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> -
>
> There's no sense in being precise when you don't even know what you're 
> talking about.
>
>  -- John von Neumann
>
>
>
>
>

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

[ANN] Apache Maven Enforcer Plugin 1.3 Released

[Robert Scholte]

The Apache Maven team is pleased to announce the release of the Maven  
Enforcer Plugin, version 1.3


The Enforcer plugin provides goals to control certain environmental  
constraints such as Maven version, JDK version and OS family along with  
many more standard rules and user created rules.


http://maven.apache.org/enforcer/maven-enforcer-plugin/

You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-enforcer-plugin
  1.3



Release Notes - Apache Maven 2.x Enforcer Plugin - Version 1.3

** Bug
* [MENFORCER-42] - Maven-Enforcer-Plugin fails in multimodule project  
when artifacts not in repository
* [MENFORCER-123] - BannedDependencies version number not taken into  
account
* [MENFORCER-126] - requirePluginVersions misreports plugins with  
artifactIds defined through properties
* [MENFORCER-146] - requireUpperBoundDeps inneffective when  
DependencyManagement is used

* [MENFORCER-148] - Broken hyperlink on Enforcer plugin usage page
* [MENFORCER-149] - Broken links to properties of "Require OS Version"  
of Maven Enforcer Plugin

* [MENFORCER-155] - Add rule RequirePrerequisite

** Improvement
* [MENFORCER-83] - Banned dependencies should support regular  
expressions
* [MENFORCER-134] - Require Upper Bound Dependencies and matching  
Snapshot Dependencies


** New Feature
* [MENFORCER-74] - The bannedDependencies rule should support  
classifier
* [MENFORCER-75] - The bannedDependencies rule should support scope  
condition

* [MENFORCER-147] - Add RequireSameVersions
* [MENFORCER-152] - Add Rule: BanDuplicatePomDependencyVersion or  
RequireUniquePomDependencyVersion


** Task
* [MENFORCER-153] - Use Mock Repository Manager for ITs
* [MENFORCER-154] - Update maven-dependency-tree to 2.1 to make it  
work with Maven-3.1+



Enjoy,

-The Apache Maven team

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

Re: [ANN] Apache Maven Enforcer Plugin 1.3 Released

[sebb]

On 30 June 2013 20:55, Robert Scholte  wrote:
> The Apache Maven team is pleased to announce the release of the Maven
> Enforcer Plugin, version 1.3
>
> The Enforcer plugin provides goals to control certain environmental
> constraints such as Maven version, JDK version and OS family along with many
> more standard rules and user created rules.
>
> http://maven.apache.org/enforcer/maven-enforcer-plugin/

Could not find a download link for the source release.

> You should specify the version in your project's plugin configuration:
>
> 
>   org.apache.maven.plugins
>   maven-enforcer-plugin
>   1.3
> 
>

Where is the source release?

> Release Notes - Apache Maven 2.x Enforcer Plugin - Version 1.3
>
> ** Bug
> * [MENFORCER-42] - Maven-Enforcer-Plugin fails in multimodule project
> when artifacts not in repository
> * [MENFORCER-123] - BannedDependencies version number not taken into
> account
> * [MENFORCER-126] - requirePluginVersions misreports plugins with
> artifactIds defined through properties
> * [MENFORCER-146] - requireUpperBoundDeps inneffective when
> DependencyManagement is used
> * [MENFORCER-148] - Broken hyperlink on Enforcer plugin usage page
> * [MENFORCER-149] - Broken links to properties of "Require OS Version"
> of Maven Enforcer Plugin
> * [MENFORCER-155] - Add rule RequirePrerequisite
>
> ** Improvement
> * [MENFORCER-83] - Banned dependencies should support regular
> expressions
> * [MENFORCER-134] - Require Upper Bound Dependencies and matching
> Snapshot Dependencies
>
> ** New Feature
> * [MENFORCER-74] - The bannedDependencies rule should support classifier
> * [MENFORCER-75] - The bannedDependencies rule should support scope
> condition
> * [MENFORCER-147] - Add RequireSameVersions
> * [MENFORCER-152] - Add Rule: BanDuplicatePomDependencyVersion or
> RequireUniquePomDependencyVersion
>
> ** Task
> * [MENFORCER-153] - Use Mock Repository Manager for ITs
> * [MENFORCER-154] - Update maven-dependency-tree to 2.1 to make it work
> with Maven-3.1+
>
>
> Enjoy,
>
> -The Apache Maven team
>
> -
> 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 Maven Enforcer version 1.3 (take 2)

[Stephen Connolly]

On Sunday, 30 June 2013, sebb wrote:

> On 29 June 2013 11:47, Robert Scholte >
> wrote:
> > Hi Sebb,
> >
> > none of these files will end up in Maven Central, they are all used for
> > tests.
>
> However, they do end up in the source release which is published via
> the ASF mirrors.
> It's vital that all released source files have the appropriate header.


Not true, for example where a source file is in a format that does not
support comments or where the source file is data for a test case and the
presence of a comment breaks the test case...

Thus there is no requirement for *all* files to contain the license, and
hence the LICENSE file is required to be sufficient as the effective
license for all files unless the file indicates otherwise...

Now it is best practice that we put the license on as many files as
possible, but the straw-man example proves that the license is not
*required* on all files, just *recommended* on as many as possible.

Where some of the code comes under different licenses in the one code base,
then is is required that we provide some indication as to which files are
covered by which licenses. That is easiest to achieve by having license
headers, but it is not required to be such.

-Stephen


> > For me that's not enough reason to cancel the vote.
> >
> > thanks,
> >
> > Robert
> >
> > Op Thu, 27 Jun 2013 12:26:03 +0200 schreef sebb :
> >
> >
> >> On 25 June 2013 21:23, Robert Scholte  wrote:
> >>>
> >>> Hi,
> >>>
> >>> We solved 15 issues:
> >>>
> >>>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=19011
> >>>
> >>> There are still a couple of issues left in JIRA:
> >>>
> >>>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11530&status=1
> >>>
> >>> Staging repo:
> >>> https://repository.apache.org/content/repositories/maven-070/
> >>>
> >>>
> https://repository.apache.org/content/repositories/maven-070/org/apache/maven/enforcer/enforcer/1.3/enforcer-1.3-source-release.zip
> >>>
> >>> Staging site:
> >>> http://maven.apache.org/enforcer-archives/enforcer-LATEST/
> >>>
> >>> Guide to testing staged releases:
> >>> http://maven.apache.org/guides/development/guide-testing-releases.html
> >>>
> >>> Vote open for 72 hours.
> >>>
> >>> [ ] +1
> >>> [ ] +0
> >>> [X] -1
> >>
> >>
> >> There are lots of files in the source archive that don't have AL
> headers:
> >>
> >> enforcer-1.3/DEPENDENCIES
> >> enforcer-1.3/enforcer-api/src/custom-rule-sample/pom.xml
> >>
> >>
> enforcer-1.3/enforcer-api/src/custom-rule-sample/src/main/java/org/apache/maven/enforcer/rule/MyCustomRule.java
> >> enforcer-1.3/enforcer-api/src/custom-rule-sample/src/usage-pom.xml
> >> enforcer-1.3/enforcer-api/src/custom-rule-sample/usage-pom.xml
> >> enforcer-1.3/enforcer-api/src/main/assembly/custom-rule-sample.xml
> >>
> >>
> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/no-repositories/child/pom.xml
> >>
> >>
> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/no-repositories/pom.xml
> >>
> >>
> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-plugin-repositories/child/pom.xml
> >>
> >>
> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-plugin-repositories/pom.xml
> >>
> >>
> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-repositories/child/pom.xml
> >>
> >>
> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-repositories/pom.xml
> >>
> >>
> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-plugin-repositories/child/pom.xml
> >>
> >>
> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-plugin-repositories/pom.xml
> >>
> >>
> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-repositories/child/pom.xml
> >>
> >>
> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-repositories/pom.xml
> >>
> >>
> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/checkPluginPropertyVersion/pom.xml
> >>
> >>
> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/checkPluginVersionProfile/pom.xml
> >>
> >> enforcer-1.3/enforcer-rules/src/test/resourc



-- 
Sent from my phone

Re: [ANN] Apache Maven Enforcer Plugin 1.3 Released

[Robert Scholte]

I've used the announcement template[1]
If this isn't complete, please file a Jira issue.

Robert

[1]  
http://maven.apache.org/developers/release/maven-project-release-procedure.html


Op Sun, 30 Jun 2013 22:00:54 +0200 schreef sebb :


On 30 June 2013 20:55, Robert Scholte  wrote:

The Apache Maven team is pleased to announce the release of the Maven
Enforcer Plugin, version 1.3

The Enforcer plugin provides goals to control certain environmental
constraints such as Maven version, JDK version and OS family along with  
many

more standard rules and user created rules.

http://maven.apache.org/enforcer/maven-enforcer-plugin/


Could not find a download link for the source release.


You should specify the version in your project's plugin configuration:


  org.apache.maven.plugins
  maven-enforcer-plugin
  1.3




Where is the source release?


Release Notes - Apache Maven 2.x Enforcer Plugin - Version 1.3

** Bug
* [MENFORCER-42] - Maven-Enforcer-Plugin fails in multimodule  
project

when artifacts not in repository
* [MENFORCER-123] - BannedDependencies version number not taken into
account
* [MENFORCER-126] - requirePluginVersions misreports plugins with
artifactIds defined through properties
* [MENFORCER-146] - requireUpperBoundDeps inneffective when
DependencyManagement is used
* [MENFORCER-148] - Broken hyperlink on Enforcer plugin usage page
* [MENFORCER-149] - Broken links to properties of "Require OS  
Version"

of Maven Enforcer Plugin
* [MENFORCER-155] - Add rule RequirePrerequisite

** Improvement
* [MENFORCER-83] - Banned dependencies should support regular
expressions
* [MENFORCER-134] - Require Upper Bound Dependencies and matching
Snapshot Dependencies

** New Feature
* [MENFORCER-74] - The bannedDependencies rule should support  
classifier

* [MENFORCER-75] - The bannedDependencies rule should support scope
condition
* [MENFORCER-147] - Add RequireSameVersions
* [MENFORCER-152] - Add Rule: BanDuplicatePomDependencyVersion or
RequireUniquePomDependencyVersion

** Task
* [MENFORCER-153] - Use Mock Repository Manager for ITs
* [MENFORCER-154] - Update maven-dependency-tree to 2.1 to make it  
work

with Maven-3.1+


Enjoy,

-The Apache Maven team

-
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: Poposed Sandbox plugins - digest and gpg:signfiles

[Brian Fox]

You mean releases that don't go to the standard release repo? Yes it's
technically possible but it becomes a dangerous thin line between
official release and one that bypasses the usual asf process.

--mobile

On Jun 22, 2013, at 8:07 PM, sebb  wrote:

> On 23 June 2013 01:00, Olivier Lamy  wrote:
>> 2013/6/23 sebb :
>>> Also, is there a Sandbox repo where the plugins can be deployed for testing?
>>> Or is it up to users to checkout the source and install the plugins locally?
>>
>> We can deploy snapshots to repository.a.o
>
> OK but what about non-snapshot versions?
> Obviously they cannot be published to the Maven Central repo, but is
> there a local repo like Codehaus have?
>
>>>
>>> -
>>> 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
>
> -
> 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 Maven Enforcer version 1.3 (take 2)

[sebb]

On 30 June 2013 21:04, Stephen Connolly  wrote:
> On Sunday, 30 June 2013, sebb wrote:
>
>> On 29 June 2013 11:47, Robert Scholte >
>> wrote:
>> > Hi Sebb,
>> >
>> > none of these files will end up in Maven Central, they are all used for
>> > tests.
>>
>> However, they do end up in the source release which is published via
>> the ASF mirrors.
>> It's vital that all released source files have the appropriate header.
>
>
> Not true, for example where a source file is in a format that does not
> support comments or where the source file is data for a test case and the
> presence of a comment breaks the test case...

That's why I wrote "appropriate".

> Thus there is no requirement for *all* files to contain the license, and
> hence the LICENSE file is required to be sufficient as the effective
> license for all files unless the file indicates otherwise...
>
> Now it is best practice that we put the license on as many files as
> possible, but the straw-man example proves that the license is not
> *required* on all files, just *recommended* on as many as possible.

Which has not happened here.

> Where some of the code comes under different licenses in the one code base,
> then is is required that we provide some indication as to which files are
> covered by which licenses. That is easiest to achieve by having license
> headers, but it is not required to be such.

Again "appropriate" applies here.

> -Stephen
>
>
>> > For me that's not enough reason to cancel the vote.
>> >
>> > thanks,
>> >
>> > Robert
>> >
>> > Op Thu, 27 Jun 2013 12:26:03 +0200 schreef sebb :
>> >
>> >
>> >> On 25 June 2013 21:23, Robert Scholte  wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> We solved 15 issues:
>> >>>
>> >>>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=19011
>> >>>
>> >>> There are still a couple of issues left in JIRA:
>> >>>
>> >>>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11530&status=1
>> >>>
>> >>> Staging repo:
>> >>> https://repository.apache.org/content/repositories/maven-070/
>> >>>
>> >>>
>> https://repository.apache.org/content/repositories/maven-070/org/apache/maven/enforcer/enforcer/1.3/enforcer-1.3-source-release.zip
>> >>>
>> >>> Staging site:
>> >>> http://maven.apache.org/enforcer-archives/enforcer-LATEST/
>> >>>
>> >>> Guide to testing staged releases:
>> >>> http://maven.apache.org/guides/development/guide-testing-releases.html
>> >>>
>> >>> Vote open for 72 hours.
>> >>>
>> >>> [ ] +1
>> >>> [ ] +0
>> >>> [X] -1
>> >>
>> >>
>> >> There are lots of files in the source archive that don't have AL
>> headers:
>> >>
>> >> enforcer-1.3/DEPENDENCIES
>> >> enforcer-1.3/enforcer-api/src/custom-rule-sample/pom.xml
>> >>
>> >>
>> enforcer-1.3/enforcer-api/src/custom-rule-sample/src/main/java/org/apache/maven/enforcer/rule/MyCustomRule.java
>> >> enforcer-1.3/enforcer-api/src/custom-rule-sample/src/usage-pom.xml
>> >> enforcer-1.3/enforcer-api/src/custom-rule-sample/usage-pom.xml
>> >> enforcer-1.3/enforcer-api/src/main/assembly/custom-rule-sample.xml
>> >>
>> >>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/no-repositories/child/pom.xml
>> >>
>> >>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/no-repositories/pom.xml
>> >>
>> >>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-plugin-repositories/child/pom.xml
>> >>
>> >>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-plugin-repositories/pom.xml
>> >>
>> >>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-repositories/child/pom.xml
>> >>
>> >>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/snapshot-repositories/pom.xml
>> >>
>> >>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-plugin-repositories/child/pom.xml
>> >>
>> >>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-plugin-repositories/pom.xml
>> >>
>> >>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-repositories/child/pom.xml
>> >>
>> >>
>> enforcer-1.3/enforcer-rules/src/test/resources/requireNoRepositories/with-repositories/pom.xml
>> >>
>> >>
>> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/checkPluginPropertyVersion/pom.xml
>> >>
>> >>
>> enforcer-1.3/enforcer-rules/src/test/resources/requirePluginVersions/checkPluginVersionProfile/pom.xml
>> >>
>> >> enforcer-1.3/enforcer-rules/src/test/resourc
>
>
>
> --
> Sent from my phone

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

Re: Release process updates (try 2)

[sebb]

On 30 June 2013 19:48, Fred Cooke  wrote:
> For Git the only thing that is needed is the unique 40 character hash such
> as this:
>
> FreeAir:youtube-dl fred$ git rev-parse HEAD
> 48bfb5f2387ab47e1973d9db0782a9af66ffc4e6

OK, so what is the Git command to download a copy of the sources that
are part of the hash?
Don't I need to know something about the Git repo it comes from?
Or are Git hashes guaranteed to be universally unique?

> It's just sloppy not to do this; if a quality release process is required,
> so is the SVN rev number. If "good enough" is OK, then it can be omitted
> because you can, most of the time, just guess. Guessing = mistakes, though.

Sorry, I have to disagree there; the source reference cannot be
omitted under any circumstances because it's not possible to review
the source release without a reference to the files in SCM. There's no
way to determine provenance otherwise.

> Fred.
>
> On Sun, Jun 30, 2013 at 8:20 PM, sebb  wrote:
>
>> The mission of the ASF is to release software as source, and to ensure
>> that the released source is available under the Apache Licence.
>>
>> Before a release can be approved it must be voted on by the PMC.
>> The review process needs to establish that the proposed source release
>> meets those aims.
>>
>> It's all but impossible for reviewers to examine every single file in
>> a source archive to determine if it meets the criteria.
>>
>> However, PMCs are also required to check what is added to the SCM
>> (SVN/Git) to make sure it meets the required license criteria.
>> This is done on an ongoing basis as part of reviewing check-ins and
>> accepting new contributions.
>>
>> So provided that all the files in the source release are also present
>> in SCM, the PMC can be reasonably sure that the source release meets
>> the ASF criteria.
>>
>> Effectively the SCM can be viewed as a database of pre-approved files.
>>
>> Without having the SCM as a database of validated files, there are far
>> too many files in the average source archive to check individually.
>> And how would one check their provenance? The obvious way is to
>> compare them with the entries in SCM.
>>
>> Therefore, I contend that a release vote does not make sense without
>> a unique reference to the source files that were used to create the
>> release.
>>
>> In the case of SVN, since tags are not guaranteed immutable, the vote
>> e-mail also
>> needs the revision. The revision alone is not sufficient, because the
>> ASF SVN is shared.
>>
>> Now whether every reviewer actually checks the source archive against SCM
>> is another matter.
>>
>> But if the required SCM information is not present, it would be
>> difficult to argue that the RM had provided sufficient information for
>> a proper review to take place. In which case the vote cannot be
>> considered valid.
>>
>> The vote thread needs to provide all the information that is needed to
>> properly review the release candidate, otherwise IMO it is not a valid
>> vote.
>> This is needed both at the time of the vote, and for historic reasons
>> so the context of the vote is properly recorded.
>>
>> Please do not obscure this thread with discussions of the release
>> plugin or tags or merits of Git/SVN.
>> Such technical aspects belong in separate threads.
>> They obviously important to the process, but not the vote, which is
>> about the result.
>>
>> Reminder: all this thread is just about is adding the following lines
>> to vote e-mails:
>>
>> SVN Tag:
>>
>> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
>> (r1496317)
>>
>> or whatever the equivalent is for Git (or any other SCM that may be in
>> use at the time).
>>
>> -
>> 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: svn commit: r2333 - /release/maven/enforcer/

[sebb]

On 30 June 2013 21:25,   wrote:
> Author: rfscholte
> Date: Sun Jun 30 20:25:21 2013
> New Revision: 2333
>
> Log:
> Store all required release files of every available enforcer version

> Added:
> release/maven/enforcer/

Surely enforcer should be under release/maven/plugins?

Or maybe I have misunderstood the naming convention.

> release/maven/enforcer/enforcer-1.0-source-release.zip   (with props)
> release/maven/enforcer/enforcer-1.0-source-release.zip.asc
> release/maven/enforcer/enforcer-1.0-source-release.zip.md5
> release/maven/enforcer/enforcer-1.0.1-source-release.zip   (with props)
> release/maven/enforcer/enforcer-1.0.1-source-release.zip.asc
> release/maven/enforcer/enforcer-1.0.1-source-release.zip.md5
> release/maven/enforcer/enforcer-1.1-source-release.zip   (with props)
> release/maven/enforcer/enforcer-1.1-source-release.zip.asc
> release/maven/enforcer/enforcer-1.1-source-release.zip.md5
> release/maven/enforcer/enforcer-1.1.1-source-release.zip   (with props)
> release/maven/enforcer/enforcer-1.1.1-source-release.zip.asc
> release/maven/enforcer/enforcer-1.1.1-source-release.zip.md5
> release/maven/enforcer/enforcer-1.2-source-release.zip   (with props)
> release/maven/enforcer/enforcer-1.2-source-release.zip.asc
> release/maven/enforcer/enforcer-1.2-source-release.zip.md5

Only the currently supported release(s) are supposed to be present on
the ASF mirror system.

Superseded releases can always be fetched from the archive server, so
should be deleted from the main ASF mirror once the new release has
had a chance to be picked up by most of the mirrors.

In this case I assume the files were not yet on the archive server, so
a day or so should be allowed for that to catch up.

> release/maven/enforcer/enforcer-1.3-source-release.zip   (with props)
> release/maven/enforcer/enforcer-1.3-source-release.zip.asc
> release/maven/enforcer/enforcer-1.3-source-release.zip.md5

> Added: release/maven/enforcer/enforcer-1.0-source-release.zip
> ==
> Binary file - no diff available.
>
> Propchange: release/maven/enforcer/enforcer-1.0-source-release.zip
> --
> svn:mime-type = application/octet-stream
>
> Added: release/maven/enforcer/enforcer-1.0-source-release.zip.asc
> ==
> --- release/maven/enforcer/enforcer-1.0-source-release.zip.asc (added)
> +++ release/maven/enforcer/enforcer-1.0-source-release.zip.asc Sun Jun 30 
> 20:25:21 2013
> @@ -0,0 +1,17 @@
> +-BEGIN PGP SIGNATURE-
> +Version: GnuPG v1.4.9 (MingW32)
> +
> +iQIcBAABCgAGBQJM0IBbAAoJECBchnPcdCx85VgP+QGXt1a9h8GjkOzUj5QwuNXb
> +Eo+VBNYkR6jbpAC6UyG6dhPff17LJ0MWau9mymzoKXm0ummH3lN9T+KV/ytB8LSJ
> +8c7Lg0omAp+kl+/wLjfKPy1GYE06q49sowv6fC/h8c8zJEvOukCdPVhI05vObRFl
> +rVGXdWyn3Qp0/yzjdvbLIG1KO5w1I3Kb0mmy8Ex9RU2EvZIFWY7b4xhDFpfIFmme
> +yiWtnk0V6d7bsuHKmLcBzOSUxEzN7D6pEnFKhryQtOZY3XjgKI/jZDvM5+n2Vuww
> ++UFIdI6P68b4sPGjtJ6+ILwopKJyzQFtwI8+n47yGqrWBFTGdExTbCYBCEhjeKv9
> +6QouHlYYTQzJbE4sAYai5Tw2sHDhkXjcUWDPVRtFsm+tq4t0oS8tXJv2+0gt
> +OathI4dTeTyNzfXhp/vtiEhaUkfJuSPgbfg0HdbFpTAHpWXWLjZb53svtn2vQWGW
> +77Xnb6JeImsA0HQGaJszhP/mWaRqXekDIAO6hQSKQYnZGVfc543rdcwCNojnYgOY
> +60ByEDV0oWM68ujb5jPwp28rYR+ZCOhLHPbjooQkLKP5oUsbeexN2HEBHgKujEzx
> +VMoimltvIpl/+OyusQYDYfbme6SLdJ3OQSB0SJaUtyZNF4/s+c0E6pz9dFUYZihV
> +iE2JTzb7qDYkk/1ZDoHa
> +=xyMr
> +-END PGP SIGNATURE-
>
> Added: release/maven/enforcer/enforcer-1.0-source-release.zip.md5
> ==
> --- release/maven/enforcer/enforcer-1.0-source-release.zip.md5 (added)
> +++ release/maven/enforcer/enforcer-1.0-source-release.zip.md5 Sun Jun 30 
> 20:25:21 2013
> @@ -0,0 +1 @@
> +c2213d41ff4c00e970b66d4e6913f0c3
> \ No newline at end of file
>
> Added: release/maven/enforcer/enforcer-1.0.1-source-release.zip
> ==
> Binary file - no diff available.
>
> Propchange: release/maven/enforcer/enforcer-1.0.1-source-release.zip
> --
> svn:mime-type = application/octet-stream
>
> Added: release/maven/enforcer/enforcer-1.0.1-source-release.zip.asc
> ==
> --- release/maven/enforcer/enforcer-1.0.1-source-release.zip.asc (added)
> +++ release/maven/enforcer/enforcer-1.0.1-source-release.zip.asc Sun Jun 30 
> 20:25:21 2013
> @@ -0,0 +1,7 @@
> +-BEGIN PGP SIGNATURE-
> +Version: GnuPG v1.4.11 (GNU/Linux)
> +
> +iF4EABEIAAYFAk33rOgACgkQRmyu1uB0fVC29AEA9htb4c2Ae18e+L+W4N7fzu5z
> +zCjjgyCGVLSLj11dxF0BAL69TDnt/NPqOkhGstdW9cbhLVr8n/KhVJT4h5ctt43p
> +=wDbw
> +-END PGP SIGNATURE-
>
> Added: release/maven/en

Re: Release process updates (try 2)

[Fred Cooke]

>
> OK, so what is the Git command to download a copy of the sources that
>
are part of the hash?
>

git checkout 

Then observe the tree. You can also export an archive, though I don't
recall the exact command off the top of my hand.


> Don't I need to know something about the Git repo it comes from?
>

Yes, the URL which would be pre-agreed. Providing it would be a nice
convenience, but nothing more.


> Or are Git hashes guaranteed to be universally unique?
>

Nothing is, however within the realms of SHA1 collisions, sure. The chances
of finding a second repo for *any* other piece of software that contains
the identical hash is pretty low. The chances of finding the same hash in a
single Git repo is impractically low. I can't see how that is handled, but
the obvious way would be to just respin the commit so the date meta data
changed and the hash changed. In any case, if that's a flaw, it's a flaw of
Git, and can't be avoided. In practice, it's not a flaw at all.

> It's just sloppy not to do this; if a quality release process is required,
> > so is the SVN rev number. If "good enough" is OK, then it can be omitted
> > because you can, most of the time, just guess. Guessing = mistakes,
> though.
>
> Sorry, I have to disagree there; the source reference cannot be
> omitted under any circumstances because it's not possible to review
> the source release without a reference to the files in SCM. There's no
> way to determine provenance otherwise.
>

I was trying to be nice with "sloppy" or perhaps sarcastic. It's totally
unacceptable to me, however it seems like some people here think it's OK. I
can see their point of view, however it's too easy to do it right to
justify not doing it right. I agree with you, completely.

Fred.

Unique Git coordinates (was: Release process updates (try 2))

[sebb]

On 30 June 2013 21:56, Fred Cooke  wrote:
>>
>> OK, so what is the Git command to download a copy of the sources that
>>
> are part of the hash?
>>
>
> git checkout 

Does not work for me.

I get the following error message:

fatal: Not a git repository (or any of the parent directories): .git

This suggests that Git does not know where to download the hash from.

> Then observe the tree. You can also export an archive, though I don't
> recall the exact command off the top of my hand.
>
>
>> Don't I need to know something about the Git repo it comes from?
>>
>
> Yes, the URL which would be pre-agreed. Providing it would be a nice
> convenience, but nothing more.

Again I disagree; the reviewer should have the specific information
they need without having to look elsewhere.
And likewise it should be in the e-mail thread for historical purposes.

>
>> Or are Git hashes guaranteed to be universally unique?
>>
>
> Nothing is, however within the realms of SHA1 collisions, sure. The chances
> of finding a second repo for *any* other piece of software that contains
> the identical hash is pretty low. The chances of finding the same hash in a
> single Git repo is impractically low. I can't see how that is handled, but
> the obvious way would be to just respin the commit so the date meta data
> changed and the hash changed. In any case, if that's a flaw, it's a flaw of
> Git, and can't be avoided. In practice, it's not a flaw at all.
>
>> It's just sloppy not to do this; if a quality release process is required,
>> > so is the SVN rev number. If "good enough" is OK, then it can be omitted
>> > because you can, most of the time, just guess. Guessing = mistakes,
>> though.
>>
>> Sorry, I have to disagree there; the source reference cannot be
>> omitted under any circumstances because it's not possible to review
>> the source release without a reference to the files in SCM. There's no
>> way to determine provenance otherwise.
>>
>
> I was trying to be nice with "sloppy" or perhaps sarcastic. It's totally
> unacceptable to me, however it seems like some people here think it's OK. I
> can see their point of view, however it's too easy to do it right to
> justify not doing it right. I agree with you, completely.
>
> Fred.

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

Re: [VOTE] Apache 3.1.0

[sebb]

Another problem: the NOTICE file contains the following spurious text:

   =
   ==  NOTICE file corresponding to the section 4 d of==
   ==  the Apache License, Version 2.0,   ==
   ==  in this case for the Apache Maven distribution.==
   =

This must not be present in NOTICE files, which are required to be as
short as possible (but no shorter).

ASF NOTICE files must start as per the following example:


Apache Maven
Copyright 2001-2013 The Apache Software Foundation

This product includes software developed at
The Apache Software Foundation (http://www.apache.org/).
==

Note also that the phrase should be "developed at" not "developed by"
- the distinction is important.

Furthermore, the NOTICE file refers to additonal 3rd party software,
but there don't appear to be any LICENSE files for the software.
The licenses should either be in LICENSE.txt or linked therefrom.

-1 (non-binding)

On 30 June 2013 20:43, sebb  wrote:
> On 30 June 2013 20:00, Jason van Zyl  wrote:
>> Here are the release bits for 3.1.0:
>>
>> Release notes:
>> https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500&version=18967
>>
>> Staging repository:
>> https://repository.apache.org/content/repositories/maven-084/
>>
>> Staged distribution:
>> https://repository.apache.org/content/repositories/maven-084/org/apache/maven/apache-maven/3.1.0/
>>
>> Staged Site:
>> http://maven.apache.org/ref/3.1.0
>
> Where is the link to the KEYS file (for checking sigs)?
>
> Also link to unique file source set in SCM? (for checking source file
> provenance)
>
> -1 (non-binding) without these.
>
>> Thanks,
>>
>> Jason
>>
>> --
>> Jason van Zyl
>> Founder,  Apache Maven
>> http://twitter.com/jvanzyl
>> -
>>
>> There's no sense in being precise when you don't even know what you're 
>> talking about.
>>
>>  -- John von Neumann
>>
>>
>>
>>
>>

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

Re: svn commit: r2333 - /release/maven/enforcer/

[Robert Scholte]

Enforcer is more than only the plugin, it also contains an API for other  
developers to write their own plugins, plus a set of standard rules. These  
are always released at once. For that reason it has its own folder.


IIRC recentely we've been asked to always put the distributions in source  
control and leave it there for at least one day so it'll be backed up.
The artifact repository is not backed up, or is at least not the primary  
location for distributions.
For this time I added all available distributions, since they weren't  
there yet. The next time these will be removed and only the new  
distribution will be added.


Robert


Op Sun, 30 Jun 2013 22:35:40 +0200 schreef sebb :


On 30 June 2013 21:25,   wrote:

Author: rfscholte
Date: Sun Jun 30 20:25:21 2013
New Revision: 2333

Log:
Store all required release files of every available enforcer version



Added:
release/maven/enforcer/


Surely enforcer should be under release/maven/plugins?

Or maybe I have misunderstood the naming convention.

release/maven/enforcer/enforcer-1.0-source-release.zip   (with  
props)

release/maven/enforcer/enforcer-1.0-source-release.zip.asc
release/maven/enforcer/enforcer-1.0-source-release.zip.md5
release/maven/enforcer/enforcer-1.0.1-source-release.zip   (with  
props)

release/maven/enforcer/enforcer-1.0.1-source-release.zip.asc
release/maven/enforcer/enforcer-1.0.1-source-release.zip.md5
release/maven/enforcer/enforcer-1.1-source-release.zip   (with  
props)

release/maven/enforcer/enforcer-1.1-source-release.zip.asc
release/maven/enforcer/enforcer-1.1-source-release.zip.md5
release/maven/enforcer/enforcer-1.1.1-source-release.zip   (with  
props)

release/maven/enforcer/enforcer-1.1.1-source-release.zip.asc
release/maven/enforcer/enforcer-1.1.1-source-release.zip.md5
release/maven/enforcer/enforcer-1.2-source-release.zip   (with  
props)

release/maven/enforcer/enforcer-1.2-source-release.zip.asc
release/maven/enforcer/enforcer-1.2-source-release.zip.md5


Only the currently supported release(s) are supposed to be present on
the ASF mirror system.

Superseded releases can always be fetched from the archive server, so
should be deleted from the main ASF mirror once the new release has
had a chance to be picked up by most of the mirrors.

In this case I assume the files were not yet on the archive server, so
a day or so should be allowed for that to catch up.

release/maven/enforcer/enforcer-1.3-source-release.zip   (with  
props)

release/maven/enforcer/enforcer-1.3-source-release.zip.asc
release/maven/enforcer/enforcer-1.3-source-release.zip.md5



Added: release/maven/enforcer/enforcer-1.0-source-release.zip
==
Binary file - no diff available.

Propchange: release/maven/enforcer/enforcer-1.0-source-release.zip
--
svn:mime-type = application/octet-stream

Added: release/maven/enforcer/enforcer-1.0-source-release.zip.asc
==
--- release/maven/enforcer/enforcer-1.0-source-release.zip.asc (added)
+++ release/maven/enforcer/enforcer-1.0-source-release.zip.asc Sun Jun  
30 20:25:21 2013

@@ -0,0 +1,17 @@
+-BEGIN PGP SIGNATURE-
+Version: GnuPG v1.4.9 (MingW32)
+
+iQIcBAABCgAGBQJM0IBbAAoJECBchnPcdCx85VgP+QGXt1a9h8GjkOzUj5QwuNXb
+Eo+VBNYkR6jbpAC6UyG6dhPff17LJ0MWau9mymzoKXm0ummH3lN9T+KV/ytB8LSJ
+8c7Lg0omAp+kl+/wLjfKPy1GYE06q49sowv6fC/h8c8zJEvOukCdPVhI05vObRFl
+rVGXdWyn3Qp0/yzjdvbLIG1KO5w1I3Kb0mmy8Ex9RU2EvZIFWY7b4xhDFpfIFmme
+yiWtnk0V6d7bsuHKmLcBzOSUxEzN7D6pEnFKhryQtOZY3XjgKI/jZDvM5+n2Vuww
++UFIdI6P68b4sPGjtJ6+ILwopKJyzQFtwI8+n47yGqrWBFTGdExTbCYBCEhjeKv9
+6QouHlYYTQzJbE4sAYai5Tw2sHDhkXjcUWDPVRtFsm+tq4t0oS8tXJv2+0gt
+OathI4dTeTyNzfXhp/vtiEhaUkfJuSPgbfg0HdbFpTAHpWXWLjZb53svtn2vQWGW
+77Xnb6JeImsA0HQGaJszhP/mWaRqXekDIAO6hQSKQYnZGVfc543rdcwCNojnYgOY
+60ByEDV0oWM68ujb5jPwp28rYR+ZCOhLHPbjooQkLKP5oUsbeexN2HEBHgKujEzx
+VMoimltvIpl/+OyusQYDYfbme6SLdJ3OQSB0SJaUtyZNF4/s+c0E6pz9dFUYZihV
+iE2JTzb7qDYkk/1ZDoHa
+=xyMr
+-END PGP SIGNATURE-

Added: release/maven/enforcer/enforcer-1.0-source-release.zip.md5
==
--- release/maven/enforcer/enforcer-1.0-source-release.zip.md5 (added)
+++ release/maven/enforcer/enforcer-1.0-source-release.zip.md5 Sun Jun  
30 20:25:21 2013

@@ -0,0 +1 @@
+c2213d41ff4c00e970b66d4e6913f0c3
\ No newline at end of file

Added: release/maven/enforcer/enforcer-1.0.1-source-release.zip
==
Binary file - no diff available.

Propchange: release/maven/enforcer/enforcer-1.0.1-source-release.zip
--
svn:mime-type = application/octet-stream

Added: release/maven/enforcer/

Re: Unique Git coordinates (was: Release process updates (try 2))

[Stephen Connolly]

On Sunday, 30 June 2013, sebb wrote:

> On 30 June 2013 21:56, Fred Cooke >
> wrote:
> >>
> >> OK, so what is the Git command to download a copy of the sources that
> >>
> > are part of the hash?
> >>
> >
> > git checkout 
>
> Does not work for me.


Until I hear otherwise, the reviewers for whom this is critical (ie the
PMC) have enough context to figure out which repo the vote refers to. (Or
they just look it up from the Pom in the source bundle)

Now I am not saying that it is ideal, and given how easy it is to provide
the details, I don't think it shoud be avoided, but when reviewing policy
and procedure it is necessary to get to the root requirements so that the
changed procedure (if it gets changed) is not doing things fr the sake of
doing them...

The fable of the fve chimpanzees and the ladder and the bunch of bananas is
always relevant when reviewing procedures (every time a chip tries to climb
the ladder, power-hose them all until it stops... Eventually no chimp will
try to climb... Then start swapping out chimps one at a time Then stop
hosing and end up with a room full of chimps who will beat the crap out f
any chimp that tries to climb the ladder but they don't know *why*)



> I get the following error message:
>
> fatal: Not a git repository (or any of the parent directories): .git
>
> This suggests that Git does not know where to download the hash from.
>
> > Then observe the tree. You can also export an archive, though I don't
> > recall the exact command off the top of my hand.
> >
> >
> >> Don't I need to know something about the Git repo it comes from?
> >>
> >
> > Yes, the URL which would be pre-agreed. Providing it would be a nice
> > convenience, but nothing more.
>
> Again I disagree; the reviewer should have the specific information
> they need without having to look elsewhere.
> And likewise it should be in the e-mail thread for historical purposes.
>
> >
> >> Or are Git hashes guaranteed to be universally unique?
> >>
> >
> > Nothing is, however within the realms of SHA1 collisions, sure. The
> chances
> > of finding a second repo for *any* other piece of software that contains
> > the identical hash is pretty low. The chances of finding the same hash
> in a
> > single Git repo is impractically low. I can't see how that is handled,
> but
> > the obvious way would be to just respin the commit so the date meta data
> > changed and the hash changed. In any case, if that's a flaw, it's a flaw
> of
> > Git, and can't be avoided. In practice, it's not a flaw at all.
> >
> >> It's just sloppy not to do this; if a quality release process is
> required,
> >> > so is the SVN rev number. If "good enough" is OK, then it can be
> omitted
> >> > because you can, most of the time, just guess. Guessing = mistakes,
> >> though.
> >>
> >> Sorry, I have to disagree there; the source reference cannot be
> >> omitted under any circumstances because it's not possible to review
> >> the source release without a reference to the files in SCM. There's no
> >> way to determine provenance otherwise.
> >>
> >
> > I was trying to be nice with "sloppy" or perhaps sarcastic. It's totally
> > unacceptable to me, however it seems like some people here think it's
> OK. I
> > can see their point of view, however it's too easy to do it right to
> > justify not doing it right. I agree with you, completely.
> >
> > Fred.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org 
> For additional commands, e-mail: dev-h...@maven.apache.org 
>
>

-- 
Sent from my phone

Re: svn commit: r2333 - /release/maven/enforcer/

[sebb]

On 30 June 2013 22:36, Robert Scholte  wrote:
> Enforcer is more than only the plugin, it also contains an API for other
> developers to write their own plugins, plus a set of standard rules. These
> are always released at once. For that reason it has its own folder.

OK, understood.

> IIRC recentely we've been asked to always put the distributions in source
> control and leave it there for at least one day so it'll be backed up.

Not quite - the current release must remain on the ASF mirrors until superseded.

> The artifact repository is not backed up, or is at least not the primary
> location for distributions.

Agreed, that's why component pages need download links.

> For this time I added all available distributions, since they weren't there
> yet.

Yes, that's fine, but since Maven is playing catchup the older
superseded releases only really need to remain there long enough to be
archived.

> The next time these will be removed and only the new distribution will
> be added.

Not quite - the older release(s) should not be removed until a few
days after the new release has been uploaded.
This gives time for the mirrors to catch up.

> Robert
>
>
> Op Sun, 30 Jun 2013 22:35:40 +0200 schreef sebb :
>
>> On 30 June 2013 21:25,   wrote:
>>>
>>> Author: rfscholte
>>> Date: Sun Jun 30 20:25:21 2013
>>> New Revision: 2333
>>>
>>> Log:
>>> Store all required release files of every available enforcer version
>>
>>
>>> Added:
>>> release/maven/enforcer/
>>
>>
>> Surely enforcer should be under release/maven/plugins?
>>
>> Or maybe I have misunderstood the naming convention.
>>
>>> release/maven/enforcer/enforcer-1.0-source-release.zip   (with props)
>>> release/maven/enforcer/enforcer-1.0-source-release.zip.asc
>>> release/maven/enforcer/enforcer-1.0-source-release.zip.md5
>>> release/maven/enforcer/enforcer-1.0.1-source-release.zip   (with
>>> props)
>>> release/maven/enforcer/enforcer-1.0.1-source-release.zip.asc
>>> release/maven/enforcer/enforcer-1.0.1-source-release.zip.md5
>>> release/maven/enforcer/enforcer-1.1-source-release.zip   (with props)
>>> release/maven/enforcer/enforcer-1.1-source-release.zip.asc
>>> release/maven/enforcer/enforcer-1.1-source-release.zip.md5
>>> release/maven/enforcer/enforcer-1.1.1-source-release.zip   (with
>>> props)
>>> release/maven/enforcer/enforcer-1.1.1-source-release.zip.asc
>>> release/maven/enforcer/enforcer-1.1.1-source-release.zip.md5
>>> release/maven/enforcer/enforcer-1.2-source-release.zip   (with props)
>>> release/maven/enforcer/enforcer-1.2-source-release.zip.asc
>>> release/maven/enforcer/enforcer-1.2-source-release.zip.md5
>>
>>
>> Only the currently supported release(s) are supposed to be present on
>> the ASF mirror system.
>>
>> Superseded releases can always be fetched from the archive server, so
>> should be deleted from the main ASF mirror once the new release has
>> had a chance to be picked up by most of the mirrors.
>>
>> In this case I assume the files were not yet on the archive server, so
>> a day or so should be allowed for that to catch up.
>>
>>> release/maven/enforcer/enforcer-1.3-source-release.zip   (with props)
>>> release/maven/enforcer/enforcer-1.3-source-release.zip.asc
>>> release/maven/enforcer/enforcer-1.3-source-release.zip.md5
>>
>>
>>> Added: release/maven/enforcer/enforcer-1.0-source-release.zip
>>>
>>> ==
>>> Binary file - no diff available.
>>>
>>> Propchange: release/maven/enforcer/enforcer-1.0-source-release.zip
>>>
>>> --
>>> svn:mime-type = application/octet-stream
>>>
>>> Added: release/maven/enforcer/enforcer-1.0-source-release.zip.asc
>>>
>>> ==
>>> --- release/maven/enforcer/enforcer-1.0-source-release.zip.asc (added)
>>> +++ release/maven/enforcer/enforcer-1.0-source-release.zip.asc Sun Jun 30
>>> 20:25:21 2013
>>> @@ -0,0 +1,17 @@
>>> +-BEGIN PGP SIGNATURE-
>>> +Version: GnuPG v1.4.9 (MingW32)
>>> +
>>> +iQIcBAABCgAGBQJM0IBbAAoJECBchnPcdCx85VgP+QGXt1a9h8GjkOzUj5QwuNXb
>>> +Eo+VBNYkR6jbpAC6UyG6dhPff17LJ0MWau9mymzoKXm0ummH3lN9T+KV/ytB8LSJ
>>> +8c7Lg0omAp+kl+/wLjfKPy1GYE06q49sowv6fC/h8c8zJEvOukCdPVhI05vObRFl
>>> +rVGXdWyn3Qp0/yzjdvbLIG1KO5w1I3Kb0mmy8Ex9RU2EvZIFWY7b4xhDFpfIFmme
>>> +yiWtnk0V6d7bsuHKmLcBzOSUxEzN7D6pEnFKhryQtOZY3XjgKI/jZDvM5+n2Vuww
>>> ++UFIdI6P68b4sPGjtJ6+ILwopKJyzQFtwI8+n47yGqrWBFTGdExTbCYBCEhjeKv9
>>> +6QouHlYYTQzJbE4sAYai5Tw2sHDhkXjcUWDPVRtFsm+tq4t0oS8tXJv2+0gt
>>> +OathI4dTeTyNzfXhp/vtiEhaUkfJuSPgbfg0HdbFpTAHpWXWLjZb53svtn2vQWGW
>>> +77Xnb6JeImsA0HQGaJszhP/mWaRqXekDIAO6hQSKQYnZGVfc543rdcwCNojnYgOY
>>> +60ByEDV0oWM68ujb5jPwp28rYR+ZCOhLHPbjooQkLKP5oUsbeexN2HEBHgKujEzx
>>> +VMoimltvIpl/+OyusQYDYfbme6SLdJ3OQSB0SJaUtyZNF4/s+c0E6pz9dFUYZihV
>>> +iE2JTzb7qDYkk/1ZDoHa
>>> +=xyMr
>>> +-END P

Re: Unique Git coordinates (was: Release process updates (try 2))

[sebb]

On 30 June 2013 23:28, Stephen Connolly  wrote:
> On Sunday, 30 June 2013, sebb wrote:
>
>> On 30 June 2013 21:56, Fred Cooke >
>> wrote:
>> >>
>> >> OK, so what is the Git command to download a copy of the sources that
>> >>
>> > are part of the hash?
>> >>
>> >
>> > git checkout 
>>
>> Does not work for me.
>
>
> Until I hear otherwise, the reviewers for whom this is critical (ie the
> PMC) have enough context to figure out which repo the vote refers to. (Or
> they just look it up from the Pom in the source bundle)

This seems to be replying to the wrong thread.

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

Re: Release process updates (try 2)

[Benson Margulies]

On the one hand, I think that, in many Apache communities, comparing the
source release to the VCS is the exception and not the rule, and may never
have happened, even once. (I think that there is at least an even chance
that some crusty veteran of httpd will arrive in this thread and call me
out on this, insisting that Sebb's view is and has always been the only
right way, and some neuron in the back of my mind thinks it has seen some
reference to a tool for comparing source release packages to svn.)

However, I don't see anything _bad_ about supplying an unambiguous,
immutable, reference to the VCS, and so it would be a good thing if Maven
helped Apache projects achieve this, rather than make it harder.

So, if everyone here likes this idea, by all means let's do that. On the
other hand, if there is no consensus here, I wish that the Foundation had a
clearer venue for discussing global policies like this.




On Sun, Jun 30, 2013 at 4:56 PM, Fred Cooke  wrote:

> >
> > OK, so what is the Git command to download a copy of the sources that
> >
> are part of the hash?
> >
>
> git checkout 
>
> Then observe the tree. You can also export an archive, though I don't
> recall the exact command off the top of my hand.
>
>
> > Don't I need to know something about the Git repo it comes from?
> >
>
> Yes, the URL which would be pre-agreed. Providing it would be a nice
> convenience, but nothing more.
>
>
> > Or are Git hashes guaranteed to be universally unique?
> >
>
> Nothing is, however within the realms of SHA1 collisions, sure. The chances
> of finding a second repo for *any* other piece of software that contains
> the identical hash is pretty low. The chances of finding the same hash in a
> single Git repo is impractically low. I can't see how that is handled, but
> the obvious way would be to just respin the commit so the date meta data
> changed and the hash changed. In any case, if that's a flaw, it's a flaw of
> Git, and can't be avoided. In practice, it's not a flaw at all.
>
> > It's just sloppy not to do this; if a quality release process is
> required,
> > > so is the SVN rev number. If "good enough" is OK, then it can be
> omitted
> > > because you can, most of the time, just guess. Guessing = mistakes,
> > though.
> >
> > Sorry, I have to disagree there; the source reference cannot be
> > omitted under any circumstances because it's not possible to review
> > the source release without a reference to the files in SCM. There's no
> > way to determine provenance otherwise.
> >
>
> I was trying to be nice with "sloppy" or perhaps sarcastic. It's totally
> unacceptable to me, however it seems like some people here think it's OK. I
> can see their point of view, however it's too easy to do it right to
> justify not doing it right. I agree with you, completely.
>
> Fred.
>

Re: Release process updates (try 2)

[sebb]

On 30 June 2013 19:20, sebb  wrote:
> The mission of the ASF is to release software as source, and to ensure
> that the released source is available under the Apache Licence.
>
> Before a release can be approved it must be voted on by the PMC.
> The review process needs to establish that the proposed source release
> meets those aims.
>
> It's all but impossible for reviewers to examine every single file in
> a source archive to determine if it meets the criteria.
>
> However, PMCs are also required to check what is added to the SCM
> (SVN/Git) to make sure it meets the required license criteria.
> This is done on an ongoing basis as part of reviewing check-ins and
> accepting new contributions.
>
> So provided that all the files in the source release are also present
> in SCM, the PMC can be reasonably sure that the source release meets
> the ASF criteria.
>
> Effectively the SCM can be viewed as a database of pre-approved files.
>
> Without having the SCM as a database of validated files, there are far
> too many files in the average source archive to check individually.
> And how would one check their provenance? The obvious way is to
> compare them with the entries in SCM.
>
> Therefore, I contend that a release vote does not make sense without
> a unique reference to the source files that were used to create the release.
>
> In the case of SVN, since tags are not guaranteed immutable, the vote
> e-mail also
> needs the revision. The revision alone is not sufficient, because the
> ASF SVN is shared.
>
> Now whether every reviewer actually checks the source archive against SCM
> is another matter.
>
> But if the required SCM information is not present, it would be
> difficult to argue that the RM had provided sufficient information for
> a proper review to take place. In which case the vote cannot be
> considered valid.
>
> The vote thread needs to provide all the information that is needed to
> properly review the release candidate, otherwise IMO it is not a valid
> vote.
> This is needed both at the time of the vote, and for historic reasons
> so the context of the vote is properly recorded.
>
> Please do not obscure this thread with discussions of the release
> plugin or tags or merits of Git/SVN.
> Such technical aspects belong in separate threads.
> They obviously important to the process, but not the vote, which is
> about the result.
>
> Reminder: all this thread is just about is adding the following lines
> to vote e-mails:
>
> SVN Tag:
> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
> (r1496317)

An alternative is to use the URL from the commit message:

URL: http://svn.apache.org/r1496317

> or whatever the equivalent is for Git (or any other SCM that may be in
> use at the time).

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

Re: Release process updates (try 2)

[sebb]

On 30 June 2013 23:32, Benson Margulies  wrote:
> On the one hand, I think that, in many Apache communities, comparing the
> source release to the VCS is the exception and not the rule, and may never
> have happened, even once. (I think that there is at least an even chance
> that some crusty veteran of httpd will arrive in this thread and call me
> out on this, insisting that Sebb's view is and has always been the only
> right way, and some neuron in the back of my mind thinks it has seen some
> reference to a tool for comparing source release packages to svn.)
>
> However, I don't see anything _bad_ about supplying an unambiguous,
> immutable, reference to the VCS, and so it would be a good thing if Maven
> helped Apache projects achieve this, rather than make it harder.
>
> So, if everyone here likes this idea, by all means let's do that. On the
> other hand, if there is no consensus here, I wish that the Foundation had a
> clearer venue for discussing global policies like this.

I hope I don't have to argue that it is ASF policy to only release
source files whose provenance is known?

My point is that the only practical way to establish provenance of the
files in a source release is via the VCS/SCM.

The reason the VCS coords need to be in the vote mail message is to
allow a reviewer the opportunity to establish provenence.
This applies for the current vote, and any potential review that might
need to take place in the future.

>
>
>
> On Sun, Jun 30, 2013 at 4:56 PM, Fred Cooke  wrote:
>
>> >
>> > OK, so what is the Git command to download a copy of the sources that
>> >
>> are part of the hash?
>> >
>>
>> git checkout 
>>
>> Then observe the tree. You can also export an archive, though I don't
>> recall the exact command off the top of my hand.
>>
>>
>> > Don't I need to know something about the Git repo it comes from?
>> >
>>
>> Yes, the URL which would be pre-agreed. Providing it would be a nice
>> convenience, but nothing more.
>>
>>
>> > Or are Git hashes guaranteed to be universally unique?
>> >
>>
>> Nothing is, however within the realms of SHA1 collisions, sure. The chances
>> of finding a second repo for *any* other piece of software that contains
>> the identical hash is pretty low. The chances of finding the same hash in a
>> single Git repo is impractically low. I can't see how that is handled, but
>> the obvious way would be to just respin the commit so the date meta data
>> changed and the hash changed. In any case, if that's a flaw, it's a flaw of
>> Git, and can't be avoided. In practice, it's not a flaw at all.
>>
>> > It's just sloppy not to do this; if a quality release process is
>> required,
>> > > so is the SVN rev number. If "good enough" is OK, then it can be
>> omitted
>> > > because you can, most of the time, just guess. Guessing = mistakes,
>> > though.
>> >
>> > Sorry, I have to disagree there; the source reference cannot be
>> > omitted under any circumstances because it's not possible to review
>> > the source release without a reference to the files in SCM. There's no
>> > way to determine provenance otherwise.
>> >
>>
>> I was trying to be nice with "sloppy" or perhaps sarcastic. It's totally
>> unacceptable to me, however it seems like some people here think it's OK. I
>> can see their point of view, however it's too easy to do it right to
>> justify not doing it right. I agree with you, completely.
>>
>> Fred.
>>

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

maven-surefire pull request: Parallel Computer

[Tibor17]

GitHub user Tibor17 opened a pull request:

https://github.com/apache/maven-surefire/pull/25

Parallel Computer

This is an implementation of PC moved from my private repo to surefire 
project.
It will fix and improve the PC.

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/Tibor17/maven-surefire master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/maven-surefire/pull/25.patch






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

Re: [VOTE] Apache 3.1.0

[Mark Derricutt]

Jason van Zyl wrote:

Staged distribution:
https://repository.apache.org/content/repositories/maven-084/org/apache/maven/apache-maven/3.1.0/
+1 non-binding on the binary/execution, seems to work fine on a mixture 
of my projects.


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

Re: Maven 3.1.0-beta-1

[Jason van Zyl]

It may be Maven or one of the plugins that changed as a result of updating the 
default plugins. I have a several very large builds and performance seems the 
same. I will set up the performance framework for the core[1], and I have a 
profiler for plugins that I will cleanup. I think it best to get the release 
out and many things will shake out and need to be fixed, and part of that 
should be enabling the performance tests to make sure that it doesn't slip.

[1]: https://github.com/tesla/maven-performance-tests
On Jun 30, 2013, at 3:21 PM, Dennis Lundberg  wrote:

> Hi
> 
> I see this as well in our corporate aggregator POM that builds everything.
> This 124 module build succeeds with Maven 3.0.5, but fails with
> java.lang.OutOfMemoryError: PermGen space
> after 108 modules when using Maven 3.1.0-alpha-1.
> 
> Sorry but I can't share the project.
> Are there any free tools that I can use to provide a permgen dump?
> 
> 
> 
> On Wed, Jun 26, 2013 at 2:23 PM, Jörg Schaible
> wrote:
> 
>> Hi Jason,
>> 
>> Jason van Zyl wrote:
>> 
>>> Doesn't see to be a whole lot of activity around the 3.1.0-alpha-1 so I
>>> plan to cut the 3.1.0-beta-1 this weekend if there are no objections.
>> 
>> Apart from the reported bogus build with snapshots (MNG-5207) it seems M31
>> has a major problem with PermGen space leakage.
>> 
>> We have currently a build that contains 337 projects. With M221 I can build
>> all of it in one run in ~11 minutes.
>> 
>> With M305 the build runs faster, but I have to continue it two times with
>> "-
>> rf" option, because it runs out of PermGen space.
>> 
>> With M31a the leakage is really worse. The build stops because of PermGen
>> space 4 times, where I have to continue manually again.
>> 
>> All plugins are locked down, so it has to be related with Maven core.
>> MAVEN_OPTS is "-Xmx1g -XX:MaxPermSize=192m" and I am running "mvn clean
>> install [-rf ]".
>> 
>> Thanks,
>> Jörg
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>> 
>> 
> 
> 
> -- 
> Dennis Lundberg

Thanks,

Jason

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

We all have problems. How we deal with them is a measure of our worth.

 -- Unknown

Re: [VOTE] Apache 3.1.0

[Barrie Treloar]

On 1 July 2013 06:52, sebb  wrote:
> Another problem: the NOTICE file contains the following spurious text:
>
>=
>==  NOTICE file corresponding to the section 4 d of==
>==  the Apache License, Version 2.0,   ==
>==  in this case for the Apache Maven distribution.==
>=
>
> This must not be present in NOTICE files, which are required to be as
> short as possible (but no shorter).
>
> ASF NOTICE files must start as per the following example:
>
> 
> Apache Maven
> Copyright 2001-2013 The Apache Software Foundation
>
> This product includes software developed at
> The Apache Software Foundation (http://www.apache.org/).
> ==
>
> Note also that the phrase should be "developed at" not "developed by"
> - the distinction is important.
>
> Furthermore, the NOTICE file refers to additonal 3rd party software,
> but there don't appear to be any LICENSE files for the software.
> The licenses should either be in LICENSE.txt or linked therefrom.

>From what I can tell we have been failing this since August 2010.
https://git-wip-us.apache.org/repos/asf?p=maven.git;a=blob;f=apache-maven/NOTICE.txt;hb=bfaf11090a212f8445f2ad929af8acce5a984bf0

I can't find change history for
http://www.apache.org/legal/src-headers.html so I don't know if we
have been failing all the time, or since it was changed.

And I can see you've raised http://jira.codehaus.org/browse/MNG-5487
to track this.

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

Re: Release process updates

[Olivier Lamy]

2013/6/26 sebb :
> The mission of the ASF is to release software as source, and to ensure
> that the released source is available under the Apache Licence.

Excuse me but I have always understand the ASF mission as building
communities around softwares.
Community over Code and not Process over Code.

I believe (my personal opinion) we are here to make two communities
happy: dev community with easing their task to build and release good
software for the users community.

With all of those emails, it's just a way to discourage people who
want to release software for their users.
Yes too much (non useful) process tend/will discourage volunteers to
release something.

My 0,02AUD
--
Olivier


>
> Before a release can be approved it must be voted on by the PMC.
> The review process needs to establish that the proposed source release
> meets those aims.
>
> It's all but impossible for reviewers to examine every single file in
> a source archive to determine if it meets the criteria.
> And it's not unknown for spurious files to creep into a release
> (perhaps from a stale workspace - are releases always built from a
> fresh checkout of the tag?)
>
> However, PMCs are also required to check what is added to the SCM
> (SVN/Git) to make sure it meets the required license criteria.
> This is done on an ongoing basis as part of reviewing check-ins and
> accepting new contributions.
> So provided that all the files in the source release are also present
> in SCM, the PMC can be reasonably sure that the source release meets
> the ASF criteria.
>
> Without having the SCM as a database of validated files, there are far
> too many files in the average source archive to check individually.
> And how would one check their provenance? The obvious way is to
> compare them with the entries in SCM.
>
> Therefore, I contend that a release vote does not make sense without
> the SCM tag.
> In the case of SVN, since tags are not immutable, the vote e-mail also
> needs the revision.
>
> Whether every reviewer actually checks the source archive against SCM
> is another matter.
> But if the required SCM information is not present, it would be
> difficult to argue that the RM had provided sufficient information for
> a valid review to take place.
>
> -
> 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: Release process updates (try 2)

[Chris Graham]

On Mon, Jul 1, 2013 at 4:20 AM, sebb  wrote:

> Reminder: all this thread is just about is adding the following lines
> to vote e-mails:
>
> SVN Tag:
>
> https://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1/
> (r1496317
> )
>
>
I still find this redundant. Given that the tag will not change for the
time window of the vote, and that the tag has it's own revision no, and you
can derive the revision from the tag, so I see no need to quote the
revision no.

In the event of a failed vote, the version/tag will be reused and it will
have a new revision, which also will be derivable.

In the event of a successful vote, the tag will remain permanently.

Should anyone ever wish to trawl through the (svn) history, then you will
still be able to see the intermediate/failed votes and history. And you'd
also need the archives of this list to address why the vote failed etc.

or whatever the equivalent is for Git (or any other SCM that may be in
> use at the time).
>
> Yes, others wil have their own requirements.