Potential contribution for Maven/JMeter
A Danish company have been working on a Maven plugin for JMeter, and are willing to contribute the code to either Maven or JMeter projects: http://www.nabble.com/Contribution--tf4578005.html Is this the sort of contribution that the Maven project would be interested in? Although it is targeted at JMeter, I imagine the bulk of the code is Maven oriented. Any views? Sebastian - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Fwd: DOAP Error Report
This started failing when the SVN repo was organised. Please can someone update https://svn.apache.org/repos/asf/infrastructure/site-tools/trunk/projects/files.xml with the new location for the DOAP? -- Forwarded message -- From: aps...@apache.org aps...@apache.org Date: 13 Sep 2009 01:30 Subject: DOAP Error Report To: Site Development site-...@apache.org Errors getting files Failed to get 'http://svn.apache.org/repos/asf/maven/components/trunk/doap_Maven.rdf' Status = 'HTTP/1.1 404 Not Found ' Processing errors - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Maven 2.0.11 Released
On 26/02/2010, Brett Porter br...@apache.org wrote: The Apache Maven team would like to announce the release of Maven 2.0.11. http://maven.apache.org/download.html This release is intended for all current users of Maven 2.0.10 and below who are not able to upgrade to Maven 2.2.1, and contains 37 improvements and fixes. What happened to the Maven 2.1.x line? 2.1.0 runs on Java 1.4.2. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Recommended procedure for fixing hash file syntax
What is the recommended procedure for fixing hash files in a Maven repo that have the wrong syntax? For example: file.tar.gz.sha1: file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB 52F3 3B4C The hash is correct, but not all tools can process the hash when it is split over two lines and has spaces in the hex string. Any advice? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Recommended procedure for fixing hash file syntax
What is the recommended procedure for fixing hash files in a Maven repo that have the wrong syntax? For example: file.tar.gz.sha1: file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB 52F3 3B4C The hash is correct, but not all tools can process the hash when it is split over two lines and has spaces in the hex string. Any advice on how best to fix this? Can I just replace the hash files in the Apache release repository with the fixed versions? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Recommended procedure for fixing hash file syntax
On 26/04/2010, sebb seb...@gmail.com wrote: What is the recommended procedure for fixing hash files in a Maven repo that have the wrong syntax? I have seen the reply about using Nexus, but if the project does not use Nexus, what is the procedure? If I update the hashes in the release repo will these be propagated to the central repo? And is that procedure permitted by the central repo rules? For example: file.tar.gz.sha1: file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB 52F3 3B4C The hash is correct, but not all tools can process the hash when it is split over two lines and has spaces in the hex string. Any advice on how best to fix this? Can I just replace the hash files in the Apache release repository with the fixed versions? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Recommended procedure for fixing hash file syntax
On 28/04/2010, Juven Xu ju...@sonatype.com wrote:
you can use these shell scripts:
find . -type f | xargs -i sh -c 'sha1sum {} | cut -d -f1 {}.sha1'
find . -type f | xargs -i sh -c 'md5sum {} | cut -d -f1 {}.md5'
Thanks, I have already created the fixed hashes.
[BTW, the find command above needs to be changed, otherwise it will
create md5 hashes for the sha1 hashes it has just created. Also, not
all versions of xargs support the -i flag. Nor are sha1sum and md5sum
universally available.]
release artifacts and their hashes in central will never be updated unless
manual fix is needed.
So how does the Nexus solution work if manual intervention is required?
if your artifacts' hashes in central are incorrect, tell me what are them so
I can fix.
The problem is with commons-compress-1.0:
http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/
e.g.
commons-compress-1.0-bin.tar.gz.md5:
commons-compress-1.0-bin.tar.gz: F8 F0 2E 1E AC 08 37 7D 75 14 CB 94 87 AF E2
C9
All the other hashes have the wrong syntax too.
On Wed, Apr 28, 2010 at 10:12 PM, sebb seb...@gmail.com wrote:
On 26/04/2010, sebb seb...@gmail.com wrote:
What is the recommended procedure for fixing hash files in a Maven
repo that have the wrong syntax?
I have seen the reply about using Nexus, but if the project does not
use Nexus, what is the procedure?
If I update the hashes in the release repo will these be propagated to
the central repo?
And is that procedure permitted by the central repo rules?
For example:
file.tar.gz.sha1:
file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB 52F3
3B4C
The hash is correct, but not all tools can process the hash when it is
split over two lines and has spaces in the hex string.
Any advice on how best to fix this?
Can I just replace the hash files in the Apache release repository
with the fixed versions?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
- juven
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Recommended procedure for fixing hash file syntax
On 28/04/2010, Juven Xu ju...@sonatype.com wrote:
On Wed, Apr 28, 2010 at 11:05 PM, sebb seb...@gmail.com wrote:
On 28/04/2010, Juven Xu ju...@sonatype.com wrote:
you can use these shell scripts:
find . -type f | xargs -i sh -c 'sha1sum {} | cut -d -f1 {}.sha1'
find . -type f | xargs -i sh -c 'md5sum {} | cut -d -f1 {}.md5'
Thanks, I have already created the fixed hashes.
[BTW, the find command above needs to be changed, otherwise it will
create md5 hashes for the sha1 hashes it has just created. Also, not
all versions of xargs support the -i flag. Nor are sha1sum and md5sum
universally available.]
yes, assume xargs -i , sha1sum, md5sum is supported:
find . -type f | grep -e 'md5$' -e 'sha1$' -v | xargs -i sh -c 'sha1sum {} |
cut -d -f1 {}.sha1'
Which will still create hashes for .asc files...
release artifacts and their hashes in central will never be updated
unless
manual fix is needed.
So how does the Nexus solution work if manual intervention is required?
It's central, has nothing to do with Nexus, currently I will fix any central
artifacts problem
if your artifacts' hashes in central are incorrect, tell me what are
them so
I can fix.
The problem is with commons-compress-1.0:
http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/
e.g.
commons-compress-1.0-bin.tar.gz.md5:
commons-compress-1.0-bin.tar.gz: F8 F0 2E 1E AC 08 37 7D 75 14 CB 94 87 AF
E2
C9
All the other hashes have the wrong syntax too.
fixed
Thanks, but you have also created unnecessary hashes for the .asc files.
Please can those be deleted?
On Wed, Apr 28, 2010 at 10:12 PM, sebb seb...@gmail.com wrote:
On 26/04/2010, sebb seb...@gmail.com wrote:
What is the recommended procedure for fixing hash files in a Maven
repo that have the wrong syntax?
I have seen the reply about using Nexus, but if the project does not
use Nexus, what is the procedure?
If I update the hashes in the release repo will these be propagated to
the central repo?
And is that procedure permitted by the central repo rules?
For example:
file.tar.gz.sha1:
file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB 52F3
3B4C
The hash is correct, but not all tools can process the hash when it
is
split over two lines and has spaces in the hex string.
Any advice on how best to fix this?
Can I just replace the hash files in the Apache release repository
with the fixed versions?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
- juven
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
- juven
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Recommended procedure for fixing hash file syntax
OK thanks very much.
If this problem recurs with other projects, is there a formal means of
reporting it?
e.g. via an issue tracker?
On 29/04/2010, Juven Xu ju...@sonatype.com wrote:
checksums on pgp signautes are deleted.
On Wed, Apr 28, 2010 at 11:34 PM, sebb seb...@gmail.com wrote:
On 28/04/2010, Juven Xu ju...@sonatype.com wrote:
On Wed, Apr 28, 2010 at 11:05 PM, sebb seb...@gmail.com wrote:
On 28/04/2010, Juven Xu ju...@sonatype.com wrote:
you can use these shell scripts:
find . -type f | xargs -i sh -c 'sha1sum {} | cut -d -f1
{}.sha1'
find . -type f | xargs -i sh -c 'md5sum {} | cut -d -f1
{}.md5'
Thanks, I have already created the fixed hashes.
[BTW, the find command above needs to be changed, otherwise it will
create md5 hashes for the sha1 hashes it has just created. Also, not
all versions of xargs support the -i flag. Nor are sha1sum and md5sum
universally available.]
yes, assume xargs -i , sha1sum, md5sum is supported:
find . -type f | grep -e 'md5$' -e 'sha1$' -v | xargs -i sh -c 'sha1sum
{} |
cut -d -f1 {}.sha1'
Which will still create hashes for .asc files...
release artifacts and their hashes in central will never be updated
unless
manual fix is needed.
So how does the Nexus solution work if manual intervention is
required?
It's central, has nothing to do with Nexus, currently I will fix any
central
artifacts problem
if your artifacts' hashes in central are incorrect, tell me what
are
them so
I can fix.
The problem is with commons-compress-1.0:
http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/
e.g.
commons-compress-1.0-bin.tar.gz.md5:
commons-compress-1.0-bin.tar.gz: F8 F0 2E 1E AC 08 37 7D 75 14 CB 94
87 AF
E2
C9
All the other hashes have the wrong syntax too.
fixed
Thanks, but you have also created unnecessary hashes for the .asc files.
Please can those be deleted?
On Wed, Apr 28, 2010 at 10:12 PM, sebb seb...@gmail.com wrote:
On 26/04/2010, sebb seb...@gmail.com wrote:
What is the recommended procedure for fixing hash files in a
Maven
repo that have the wrong syntax?
I have seen the reply about using Nexus, but if the project does
not
use Nexus, what is the procedure?
If I update the hashes in the release repo will these be
propagated to
the central repo?
And is that procedure permitted by the central repo rules?
For example:
file.tar.gz.sha1:
file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB 52F3
3B4C
The hash is correct, but not all tools can process the hash
when it
is
split over two lines and has spaces in the hex string.
Any advice on how best to fix this?
Can I just replace the hash files in the Apache release
repository
with the fixed versions?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
- juven
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
- juven
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
- juven
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Recommended procedure for fixing hash file syntax
On 29/04/2010, Brett Porter br...@apache.org wrote:
The correct one for reporting problems (vs new uploads) is:
http://jira.codehaus.org/browse/MEV
In general, you want to make sure it is fixed at the source first if it's an
imported forge like Apache's.
So, is the correct procedure as follows:
1) Update the hash files on the imported repository, in this case the
Apache release repo.
2) Raise an MEV JIRA issue to get the hashes updated on the central repo.
Or have I misunderstood something?
- Brett
On 29/04/2010, at 9:45 PM, Juven Xu wrote:
I think people can create tasks here:
http://jira.codehaus.org/browse/MAVENUPLOAD
or at Sonatype:
https://issues.sonatype.org/browse/OSSRH
On Thu, Apr 29, 2010 at 4:12 PM, sebb seb...@gmail.com wrote:
OK thanks very much.
If this problem recurs with other projects, is there a formal means of
reporting it?
e.g. via an issue tracker?
On 29/04/2010, Juven Xu ju...@sonatype.com wrote:
checksums on pgp signautes are deleted.
On Wed, Apr 28, 2010 at 11:34 PM, sebb seb...@gmail.com wrote:
On 28/04/2010, Juven Xu ju...@sonatype.com wrote:
On Wed, Apr 28, 2010 at 11:05 PM, sebb seb...@gmail.com wrote:
On 28/04/2010, Juven Xu ju...@sonatype.com wrote:
you can use these shell scripts:
find . -type f | xargs -i sh -c 'sha1sum {} | cut -d -f1
{}.sha1'
find . -type f | xargs -i sh -c 'md5sum {} | cut -d -f1
{}.md5'
Thanks, I have already created the fixed hashes.
[BTW, the find command above needs to be changed, otherwise it
will
create md5 hashes for the sha1 hashes it has just created. Also,
not
all versions of xargs support the -i flag. Nor are sha1sum and
md5sum
universally available.]
yes, assume xargs -i , sha1sum, md5sum is supported:
find . -type f | grep -e 'md5$' -e 'sha1$' -v | xargs -i sh -c
'sha1sum
{} |
cut -d -f1 {}.sha1'
Which will still create hashes for .asc files...
release artifacts and their hashes in central will never be
updated
unless
manual fix is needed.
So how does the Nexus solution work if manual intervention is
required?
It's central, has nothing to do with Nexus, currently I will fix any
central
artifacts problem
if your artifacts' hashes in central are incorrect, tell me
what
are
them so
I can fix.
The problem is with commons-compress-1.0:
http://repo1.maven.org/maven2/org/apache/commons/commons-compress/1.0/
e.g.
commons-compress-1.0-bin.tar.gz.md5:
commons-compress-1.0-bin.tar.gz: F8 F0 2E 1E AC 08 37 7D 75 14
CB 94
87 AF
E2
C9
All the other hashes have the wrong syntax too.
fixed
Thanks, but you have also created unnecessary hashes for the .asc
files.
Please can those be deleted?
On Wed, Apr 28, 2010 at 10:12 PM, sebb seb...@gmail.com
wrote:
On 26/04/2010, sebb seb...@gmail.com wrote:
What is the recommended procedure for fixing hash files in
a
Maven
repo that have the wrong syntax?
I have seen the reply about using Nexus, but if the project
does
not
use Nexus, what is the procedure?
If I update the hashes in the release repo will these be
propagated to
the central repo?
And is that procedure permitted by the central repo rules?
For example:
file.tar.gz.sha1:
file.tar.gz: B886 07FA D17D 06C2 7D67 01D6 E7E6 56BB
52F3
3B4C
The hash is correct, but not all tools can process the
hash
when it
is
split over two lines and has spaces in the hex string.
Any advice on how best to fix this?
Can I just replace the hash files in the Apache release
repository
with the fixed versions?
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
- juven
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
- juven
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
- juven
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
--
- juven
--
Brett Porter
br...@apache.org
http://brettporter.wordpress.com
Re: Julia Antonova/Tumlare is out of office.
Maybe someone should let her colleagues in on the fun that can be had from OoO autoreplies ;-) I wonder if the company realises how much internal information is being allowed to leak out in OoO autoreplies... On 30/04/2010, John Casey jdca...@commonjava.org wrote: nice! On 4/30/10 3:33 PM, Tim O'Brien wrote: Ok, I'm glad we were all prepared for this. I've made sure to update the Maven FAQ to include this info for others that might be confused: http://docs.codehaus.org/display/MAVENUSER/FAQs-1#FAQs-1-IsJuliaAntonova%2FTumlareoutoftheoffice%3F On Fri, Apr 30, 2010 at 2:17 PM, John Caseyjdca...@commonjava.org wrote: It's good to ALWAYS know just where Julia is...or, rather, isn't. On 4/30/10 3:11 PM, Julia Antonova wrote: I will be out of the office starting 30.04.2010 and will not return until 04.05.2010. I have no acces to my mailbox, I will reply to your message upon return. For urgent issues please contact my colleagues: Sergey Khomyakov / Administration - serge...@tumlare.com Irina Pashina / Administration - secretary...@tumlare.com - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: State of checksums?
On 03/05/2010, Brett Porter br...@apache.org wrote: On 01/05/2010, at 3:19 AM, Benjamin Bentmann wrote: Hi, considering the recent fixes to checksums for stuff in central, I was wondering what's the overall state of (existing) checksums on central these days? Probably still not great. We aren't using these for an integrity-of-the-repository purpose, so perhaps it's a good time to automatically fix them on central (keeping a record of what was changed, and what it used to be just in case), then turn on the fail option by default. You can be sure if it fails by default that content will be more carefully managed :) Seems to me that ideally the problems should be fixed at source, i.e. on the forge (if that's the correct Maven term) that provided the original data. Unless there is some independent way of checking that the files being hashed are the correct files, creating new hashes seems like a bad idea, as it would allow a corrupt version to be introduced. Creating new hashes is very different from fixing the format of hash files. Seems to me that the first step is to prevent any new files being added to central unless they have valid hashes and signatures to stop the problem getting worse - or has that already been done? Assuming checksums are correct where present, this should put us in a good position to introduce a new checksum policy fail-if-present or just strict some day. The difference to the existing fail policy would be to only fail the build if at least one checksum file to verify is actually present. Making this policy the default for central would reduce the grief caused by Maven happily downloading HTTP status pages and trying to build class paths from HTML files... Benjamin - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - 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
Problem with Apache Parent Pom version 7
The Apache parent pom version 7 seems to require Java 1.5 (because maven-remote-resources-plugin v1.1 requires Java 1.5) yet the compile.source and compile.target are 1.4. Is it intentional that AP Pom v7 requires 1.5? It would help if the Apache Parent Pom stated the minimum version of Java it is intended to support. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A legal-ish question
On 11/06/2010, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: I have a memoizer (http://www.javaconcurrencyinpractice.com/listings/Memoizer.java) that I'd like to include somewhere in our code base. It's like 30 lines of code or so. Ï've seen this snippet of code (or extremely minor permutations of it) appear a number of places, under various lisence headers, for instance: http://www.koders.com/java/fid960BDFDD3A35D42E6652E79BA3F959A375024F0B.aspx?s=mdef%3Acompute What's the appropriate thing to do IP-wise wrt including such a piece of code ? The specific implementation I've linked to appears on page 108 of the Java Concurrency in practice book. If you want to include this in ASF code, then IMO this question should be asked on the ASF legal-discuss list. Note: the covering description page [1] for the code says quote Written by Brian Goetz and Tim Peierls with assistance from members of JCP JSR-166 Expert Group and released to the public domain, as explained at http://creativecommons.org/licenses/publicdomain /quote This is a *real hard* piece of code to get right, so I'm not about to write my own. +1 to that! [1] http://www.javaconcurrencyinpractice.com/listings.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: A legal-ish question
On 11/06/2010, Brett Porter br...@apache.org wrote: On 11/06/2010, at 4:27 PM, Kristian Rosenvold wrote: I have a memoizer (http://www.javaconcurrencyinpractice.com/listings/Memoizer.java) that I'd like to include somewhere in our code base. It's like 30 lines of code or so. Ï've seen this snippet of code (or extremely minor permutations of it) appear a number of places, under various lisence headers, for instance: http://www.koders.com/java/fid960BDFDD3A35D42E6652E79BA3F959A375024F0B.aspx?s=mdef%3Acompute What's the appropriate thing to do IP-wise wrt including such a piece of code ? The specific implementation I've linked to appears on page 108 of the Java Concurrency in practice book. It's fine to include it under the terms of it's public domain license: http://www.apache.org/legal/resolved.html#category-a Huh? That does not mention Public Domain? - Brett -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ - 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: A legal-ish question
On 11/06/2010, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: fr., 11.06.2010 kl. 06.35 -0700, skrev Jason van Zyl: On Jun 10, 2010, at 11:27 PM, Kristian Rosenvold wrote: I have a memoizer (http://www.javaconcurrencyinpractice.com/listings/Memoizer.java) that I'd like to include somewhere in our code base. It's like 30 lines of code or so. Ï've seen this snippet of code (or extremely minor permutations of it) appear a number of places, under various lisence headers, for instance: http://www.koders.com/java/fid960BDFDD3A35D42E6652E79BA3F959A375024F0B.aspx?s=mdef%3Acompute What's the appropriate thing to do IP-wise wrt including such a piece of code ? The specific implementation I've linked to appears on page 108 of the Java Concurrency in practice book. It's fine, bringing anything up on the legal lists here is a waste of time. will check the code with the folks at Eclipse and let you know if there is any problem. Apache has no IP checking system at all so it's honestly generally useless asking anyone here. Eclipse has a real IP clearance mechanism with real lawyers, with a real set of tools for validation using humans, Black Duck and Palimida. If you've found a public domain license then you're fine, but I'll ask the Eclipse IP team. Sebb identified the piece of code as public domain via the official website of the book; I was looking in the hardcopy and couldn't find it in the printed book. So much for dead trees. Now the link Brett sent doesn't explicitly name Public domain as a license with compatibility constraints, but it seems implied in the section on Doug Lea's concurrent library: http://www.apache.org/legal/resolved.html#concurrent The section at http://www.apache.org/legal/resolved.html#category-a includes the link: Creative Commons Copyright-Only Dedication which links to http://creativecommons.org/licenses/publicdomain/ i.e. the same as in the http://www.javaconcurrencyinpractice.com/listings.html So I think it's clear that the link Brett supplied does apply to ASF code so long as you use the source from the JCIP site. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Which Jira to use for items concerning the Apache Common Parent POM?
On 20/05/2010, Marshall Schor m...@schor.com wrote: Hi, I've posted earlier on u...@maven.apache.org about a couple of possible improvements to the Apache Common Parent POM - used by Apache projects [1]. I'd like to add some Jira issues for these, but I was unable to determine what Jira system to use; which one should I use? I'm told that there is now a new component under the MNG project: Apache or Maven Parent poms. -Marshall Schor [1]http://repo1.maven.org/maven2/org/apache/apache/7/apache-7.pom - 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: Julia Antonova/Tumlare is out of office.
Have you seen this? http://docs.codehaus.org/display/MAVENUSER/FAQs-1#FAQs-1-IsJuliaAntonova/Tumlareoutoftheoffice? But I agree it's annoying. The problem is that there are lots of different ways of denoting OoO messages. Just matching on subject line will result in false positives. I think many of them have the header: Auto-Submitted: auto-generated which is unlikely to be present in proper postings. On 12/06/2010, Martin Gainty mgai...@hotmail.com wrote: these transmissions are annoying and rude..is there a way we can filter emails from corporate is off the list maybe a maven-filter-plugin activated by quartz scheduler that reads out of office and redirects to the round-file? bedankt, Martin __ Verzicht und Vertraulichkeitanmerkung Diese Nachricht ist vertraulich. Sollten Sie nicht der vorgesehene Empfaenger sein, so bitten wir hoeflich um eine Mitteilung. Jede unbefugte Weiterleitung oder Fertigung einer Kopie ist unzulaessig. Diese Nachricht dient lediglich dem Austausch von Informationen und entfaltet keine rechtliche Bindungswirkung. Aufgrund der leichten Manipulierbarkeit von E-Mails koennen wir keine Haftung fuer den Inhalt uebernehmen. Subject: Julia Antonova/Tumlare is out of office. From: juli...@tumlare.com To: dev@maven.apache.org Date: Sat, 12 Jun 2010 15:32:55 +0400 I will be out of the office starting 12.06.2010 and will not return until 15.06.2010. I have no acces to my mailbox, I will reply to your message upon return. For urgent issues please contact my colleagues: Sergey Khomyakov / Administration - serge...@tumlare.com Irina Pashina / Administration - secretary...@tumlare.com _ The New Busy think 9 to 5 is a cute idea. Combine multiple calendars with Hotmail. http://www.windowslive.com/campaign/thenewbusy?tile=multicalendarocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_5 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Surefire 2.6 Released
Why has SUREFIRE-536 still not been fixed? It was originally reported against 2.4.3 On 16 August 2010 15:19, Stephen Connolly steph...@apache.org wrote: The Maven team is pleased to announce the release of Surefire, version 2.6 This release includes the maven-surefire-plugin, which executes the unit tests of an application, the maven-surefire-report-plugin, which parses surefire/failsafe test results and renders them to DOXIA creating the web interface version of the test results, as well as the maven-failsafe-plugin, which executes the integration tests of an application. http://maven.apache.org/plugins/maven-surefire-plugin/ http://maven.apache.org/plugins/maven-surefire-report-plugin/ http://maven.apache.org/plugins/maven-failsafe-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.6/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-report-plugin/artifactId version2.6/version /plugin plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-failsafe-plugin/artifactId version2.6/version /plugin Release Notes - Maven Surefire - Version 2.6 ** Bug * [SUREFIRE-121] - System properties set on the command line get clobbered * [SUREFIRE-604] - failsave plugin does not execute post-integrateion-test phase after timeout via forkedProcessTimeoutInSeconds * [SUREFIRE-613] - Wrong number of JUnit4 tests when running in parallel * [SUREFIRE-621] - Parallel test execution: Test couting and reporting does not work with JUnit 3 TestSuites * [SUREFIRE-623] - Docs say that Java 1.3 is supported, but minimum version is 1.4 * [SUREFIRE-629] - NullPointerException in DemultiplexingRunListener, falsely report of No tests were executed! * [SUREFIRE-630] - maven surefire plugin with parallels skips all tests when one test has @Ignore annotation (on mac os) * [SUREFIRE-633] - Upgrade plexus-utils to avoid potential deadlocks in versions prior to 2.0.5 ** Improvement * [SUREFIRE-592] - Refactor plugins to remove duplicate code * [SUREFIRE-606] - Provide a way for multiple executions of failsafe:integration-test to communicate with failsafe:verify (and the maven-surefire-report-plugin) * [SUREFIRE-607] - Failsafe should create workingDirectory if it does not exist * [SUREFIRE-612] - Create documentation on Junit providers * [SUREFIRE-615] - Surefire providers shouldn't need to download old versions of the library * [SUREFIRE-617] - Support @threadSafe in surefire * [SUREFIRE-618] - Improve surefire parameter config * [SUREFIRE-619] - The surefire plugin should generate the test classpath ** New Feature * [SUREFIRE-576] - Have the abiltiy to remove a dependency from the test classpath (at least optional ones * [SUREFIRE-598] - run maven test with customized classpath ** Task * [SUREFIRE-594] - Create an integration test for r897240 Enjoy, -The 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: [ANN] Surefire 2.6 Released
On 16 August 2010 16:00, Stephen Connolly stephen.alan.conno...@gmail.com wrote: Does the issue have a patch? It does now. Many thanks to Stevo Slavic. Does the patch include integration tests that cover positive and negative testing? AFAIK. Is the patch against the latest code base? AFAIK. Is the patch formatted using the Maven code style? AFAIK. Does the patch exclude formatting changes on lines not affected by the patch? Yes. If the answer is yes to all of the above then I will apply the patch straight away... If there are no's then you might have to work to find a committer willing to champion your fix. If the answers are all no, then sorry out of luck I think it's unreasonable to require bug reporters to provide patches. Although they are likely to be Java developers, that does not mean that they are familiar with Maven plugins or the Maven development environment. That stance may make sense for enhancements, but for a relatively simple bug such as this I would expect the developers to be able to provide a fix, especially as the faulty code and class had already been identified. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1067521 - /maven/pom/trunk/asf/pom.xml
In which case please add some comments: - to say why URL must be www.a.o - to note the URL for the POM itself so people can find its documentation. On 9 February 2011 02:27, Brian Fox bri...@infinity.nu wrote: You realize that this may cause everyone to inherit the wrong url now? We should have the default url pointed at the apache site, not the pom site. On Sat, Feb 5, 2011 at 3:51 PM, ol...@apache.org wrote: Author: olamy Date: Sat Feb 5 20:51:25 2011 New Revision: 1067521 URL: http://svn.apache.org/viewvc?rev=1067521view=rev Log: [MPOM-7] fix url in pom Modified: maven/pom/trunk/asf/pom.xml Modified: maven/pom/trunk/asf/pom.xml URL: http://svn.apache.org/viewvc/maven/pom/trunk/asf/pom.xml?rev=1067521r1=1067520r2=1067521view=diff == --- maven/pom/trunk/asf/pom.xml (original) +++ maven/pom/trunk/asf/pom.xml Sat Feb 5 20:51:25 2011 @@ -52,7 +52,7 @@ under the License. nameThe Apache Software Foundation/name urlhttp://www.apache.org//url /organization - urlhttp://www.apache.org//url + urlhttp://maven.apache.org/asf-pom//url issueManagement systemjira/system urlhttps://issues.apache.org/jira/browse/MPOM/url - 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: r1067520 - /maven/pom/trunk/asf/pom.xml
I think this was my suggestion originally, as being one way to document how to find information on the ASF POM from the POM. I suggested using the url and issueManagement which provide the relevant information. However, a block comment would do just as well if those are needed to be set differently. [And clearly there need to be comments as to why they are set differently] S. On 9 February 2011 02:34, Brian Fox bri...@infinity.nu wrote: I see now what you've done. If you need these values for the site, then drop them into the asf-pom profile you created, but honestly I think we should move all of this and the site.xml out and find a place to put the docs into the infra site, or somewhere inside of maven. I think the asf pom project needs to be JUST the pom so that nothing inherited screws with anyone else's projects. On Tue, Feb 8, 2011 at 9:29 PM, Brian Fox bri...@infinity.nu wrote: same comment as the url, i don't think we want to be polluting the inheritence tree with specifics about the ASF wide pom project. On Sat, Feb 5, 2011 at 3:47 PM, ol...@apache.org wrote: Author: olamy Date: Sat Feb 5 20:47:25 2011 New Revision: 1067520 URL: http://svn.apache.org/viewvc?rev=1067520view=rev Log: [MPOM-7] add issueManagement to https://issues.apache.org/jira/browse/MPOM Modified: maven/pom/trunk/asf/pom.xml Modified: maven/pom/trunk/asf/pom.xml URL: http://svn.apache.org/viewvc/maven/pom/trunk/asf/pom.xml?rev=1067520r1=1067519r2=1067520view=diff == --- maven/pom/trunk/asf/pom.xml (original) +++ maven/pom/trunk/asf/pom.xml Sat Feb 5 20:47:25 2011 @@ -53,6 +53,10 @@ under the License. urlhttp://www.apache.org//url /organization urlhttp://www.apache.org//url + issueManagement + systemjira/system + urlhttps://issues.apache.org/jira/browse/MPOM/url + /issueManagement repositories repository idapache.snapshots/id - 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
Maven GPG plugin - any chance of a new release?
There are two useful fixes since 1.1, and only one outstanding bug. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
MASSEMBLY-553 - Assembly plugin ignores attached assemblies
The assembly plugin is broken for versions after 2.2-beta-5. Both 2.2 and 2.2.1 ignore attached assemblies which are defined in the parent pom when running mvn install. However the attached assemblies are processed if one runs mvn clean install or mvn package install, and they are also processed if defined in the current pom. It seems to be just inherited attaches that are ignored. Is anyone looking at this? It seems quite a serious error, which possibly exends beyond the assembly plugin itself, given that the package goal is implicitly called by install. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: MASSEMBLY-553 - Assembly plugin ignores attached assemblies
On 14 April 2011 15:26, John Casey jdca...@commonjava.org wrote: mvn package install == mvn install Except that it behaves differently, which is why I think it may be something more than just an assembly bug ... Are you talking about assemblies created by previous Maven executions, that are just lying around in file form in the target/ directory? Is there a project out there I can take a look at that will exhibit the problem? See MASSEMBLY-553 for all the details. On 4/14/11 9:20 AM, sebb wrote: The assembly plugin is broken for versions after 2.2-beta-5. Both 2.2 and 2.2.1 ignore attached assemblies which are defined in the parent pom when running mvn install. However the attached assemblies are processed if one runs mvn clean install or mvn package install, and they are also processed if defined in the current pom. It seems to be just inherited attaches that are ignored. Is anyone looking at this? It seems quite a serious error, which possibly exends beyond the assembly plugin itself, given that the package goal is implicitly called by install. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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: MASSEMBLY-553 - Assembly plugin ignores attached assemblies
On 14 April 2011 16:47, John Casey jdca...@commonjava.org wrote: On 4/14/11 11:37 AM, sebb wrote: On 14 April 2011 15:26, John Caseyjdca...@commonjava.org wrote: mvn package install == mvn install Except that it behaves differently, which is why I think it may be something more than just an assembly bug ... Are you talking about assemblies created by previous Maven executions, that are just lying around in file form in the target/ directory? Is there a project out there I can take a look at that will exhibit the problem? See MASSEMBLY-553 for all the details. I did see MASSEMBLY-553, before I replied. However, there is no SVN URL or other project attachment that I can use to see the error take place. This makes it extremely difficult to replicate the problem here. As I wrote on the JIRA a short while ago, it has an attachment with a test project that should be sufficient to reproduce the problem. Keep in mind that I'm not a commons expert. :-) You don't have to be; AFAICT this is not an issue that is specific to Commons, although that is where it was discovered. On 4/14/11 9:20 AM, sebb wrote: The assembly plugin is broken for versions after 2.2-beta-5. Both 2.2 and 2.2.1 ignore attached assemblies which are defined in the parent pom when running mvn install. However the attached assemblies are processed if one runs mvn clean install or mvn package install, and they are also processed if defined in the current pom. It seems to be just inherited attaches that are ignored. Is anyone looking at this? It seems quite a serious error, which possibly exends beyond the assembly plugin itself, given that the package goal is implicitly called by install. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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 -- John Casey Developer, PMC Member - Apache Maven (http://maven.apache.org) Blog: http://www.johnofalltrades.name/ - 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: r1127427 - /maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/Base64Test.java
On 25 May 2011 10:04, Stephen Connolly stephen.alan.conno...@gmail.com wrote: These were Nicolas' tests, but a good catch and I've made the change. BTW, the aim here is to reproduce the bugs for the first go... so if Plexus Utils is incorrectly using platform encoding then actually the test would be correct! So it may be that we revert this... should probably add an annotation around tests which are testing bugs Relying on the platform encoding in test cases to expose bugs is surely just as error prone as relying on the platform encoding in the code under test? The failures will at best only occur on certain platforms, and may never occur if the test code makes the same assumptions as the code under test. In order to test code that might rely on the platform encoding, surely the only safe way to do this is to set the default to various different encodings, including ones that are known to cause problems - e.g. Turkish and Ebcdic. On 25 May 2011 09:48, Hervé BOUTEMY herve.bout...@free.fr wrote: notice that encoding (US-ASCII or UTF-8) should be precised both when converting String to byte[] and byte[] to String, or you're implicitely using platform encoding which is not the best: if anybody tries to run tests on an EBCDIC platform, they will fail (I know, this is quite rare, but that's chicken and egg problem: it is rare because it always fail for stupid reasons, then nobody takes care of such little things) Regards, Hervé Le mercredi 25 mai 2011, steph...@apache.org a écrit : + assertThat( new String( new Base64().encode( test.getBytes() ) ), is( dGVzdA== ) ); } - 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: svn commit: r1127427 - /maven/sandbox/trunk/plexus-utils-commons-bridge/plexus-utils-tck/src/test/java/org/codehaus/plexus/util/Base64Test.java
On 26 May 2011 15:03, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 26 May 2011 12:57, sebb seb...@gmail.com wrote: On 25 May 2011 10:04, Stephen Connolly stephen.alan.conno...@gmail.com wrote: These were Nicolas' tests, but a good catch and I've made the change. BTW, the aim here is to reproduce the bugs for the first go... so if Plexus Utils is incorrectly using platform encoding then actually the test would be correct! So it may be that we revert this... should probably add an annotation around tests which are testing bugs Relying on the platform encoding in test cases to expose bugs is surely just as error prone as relying on the platform encoding in the code under test? How do you test that the code under test is using the platform encoding? I would try and set the default encoding to a special value that is bound to cause problems. I don't know how difficult it is to create a new encoding, but in theory one could create an encoding that always threw a run-time error if used. There are some bits of code in Plexus Utils that is using the platform encoding, this could be considered a bug, but it is a bug that we have to reproduce, so if your tests send platform encoding in and get platform encoding out - we know it is using platform encoding (or it's using the same encoding as platform encoding as a default) Not necessarily - in the case in point, the use of default encoding in the test code does not help show whether or not the target code is using platform encoding. The only way I can consider of testing this reliably is to keep the test code using platform encoding and have two executions of surefire, the first leaving things as is and the second with file.encoding set to a different value. Unfortunately, the file.encoding system property is only read at start-up, so two executions is the only way to be sure. The failures will at best only occur on certain platforms, and may never occur if the test code makes the same assumptions as the code under test. In order to test code that might rely on the platform encoding, surely the only safe way to do this is to set the default to various different encodings, including ones that are known to cause problems - e.g. Turkish and Ebcdic. On 25 May 2011 09:48, Hervé BOUTEMY herve.bout...@free.fr wrote: notice that encoding (US-ASCII or UTF-8) should be precised both when converting String to byte[] and byte[] to String, or you're implicitely using platform encoding which is not the best: if anybody tries to run tests on an EBCDIC platform, they will fail (I know, this is quite rare, but that's chicken and egg problem: it is rare because it always fail for stupid reasons, then nobody takes care of such little things) Regards, Hervé Le mercredi 25 mai 2011, steph...@apache.org a écrit : + assertThat( new String( new Base64().encode( test.getBytes() ) ), is( dGVzdA== ) ); } - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [RFC] Migrating Maven JIRA from jira.codehaus.org to issues.apache.org
On 1 June 2011 14:46, Brett Porter br...@apache.org wrote: On 01/06/2011, at 8:21 PM, Stephen Connolly wrote: REQUEST FOR COMMENTS: Potential migration of Maven's JIRA from jira.codehaus.org to issues.apache.org Just wondering now that codehaus and apache are on nearly similar versions (4.1.2 and 4.2.4 respectively) what would be involved. Ben@codehaus can give us a 4.1.2 dump of the entire codehaus jira and we'd just have to cull out the non-maven projects (easier way than any others is what Ben thinks as most of the projects are Maven based projects) On the Infra side, would this be the easiest way to pull the issues in? I'd been meaning to mention... As it happens, Archiva Continuum are moving their issues over already, so I have already asked Ben if he can include the Maven projects in the same test dump. That doesn't imply any commitment - they can be deleted before import - but it means we can have a look at how it would turn out. What do people think in general? +1's: * We'd be fully on Apache controlled hardware Some other advantages: - it's what some new users expect (I've had some small complaints over time about not finding it / needing another account on a different JIRA) - the subversion commits tab would work again - takes the load of Ben Codehaus :) -1's: * Since a lot of the issues end up being actually issues in a lower layer (most of which if not ASF hosted live/lived @ codehaus) or an upper layer (i.e. one of the mojo plugins) we'd loose the ability to move those issues to the correct project and instead we'd have to create a new tracking issue on the root cause project's jira I don't see that that's a big issue. * What we have works, if it ain't broke don't fix it That's a pretty powerful one :) I disagree - I think that argument would apply to moving from JIRA to some other issue tracker, not to moving to a different host and JIRA version. Besides, the current arrangement is not perfect, as has already been described. Once we have enough comments/feedback (I'm willing to give a week or two), I'll put the options to the Maven PMC who will ultimately EITHER make a decision OR delegate making a decision to all the Maven committers. -Stephen -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - 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: [RFC] Migrating Maven JIRA from jira.codehaus.org to issues.apache.org
Does Codehaus JIRA support adding SVN commit messages to issues? I've yet to see any such entries, but in the ASF JIRA this is used extensively. IMO it's a very useful feature - makes it much easier to follow what happened to an issue later on. I don't know whether the feature is not available, not enabled or just not being used in Codehaus JIRA, but on the face of it the ASF JIRA is better in this respect. On 2 June 2011 15:00, Brian Fox bri...@infinity.nu wrote: I did the m2e move a few years back from codehaus to sonatype and it was definititely non-trivial. You have to line up the workflows and fields on both sides and then you have to contend with all the user accounts that get thrown into Jira. 2011/6/1 Arnaud Héritier aherit...@gmail.com: +0. Even if it could be the best for us to have coherent systems such migration is very difficult to do as Jira provides very few things to do such changes. The export/import by project isn't transitive with all Jira internal elements (users, groups, workflows, schemes ). It is AFAIK very difficult to do and many tasks have to be done manually (or we have to write ourself some tooling). During the migration process we'll have to close the codehaus service thus we have to take care to not let our community without issues trackers for several days. Who should work on this migration ? ASF infra ? The dev team ? If it's the infra team, I say +0,5 If it's us, -0,5 (I'm not sure we have enough resources to do it for now) Arnaud On Wed, Jun 1, 2011 at 4:49 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 1 June 2011 14:46, Brett Porter br...@apache.org wrote: On 01/06/2011, at 8:21 PM, Stephen Connolly wrote: REQUEST FOR COMMENTS: Potential migration of Maven's JIRA from jira.codehaus.org to issues.apache.org Just wondering now that codehaus and apache are on nearly similar versions (4.1.2 and 4.2.4 respectively) what would be involved. Ben@codehaus can give us a 4.1.2 dump of the entire codehaus jira and we'd just have to cull out the non-maven projects (easier way than any others is what Ben thinks as most of the projects are Maven based projects) On the Infra side, would this be the easiest way to pull the issues in? I'd been meaning to mention... As it happens, Archiva Continuum are moving their issues over already, so I have already asked Ben if he can include the Maven projects in the same test dump. That doesn't imply any commitment - they can be deleted before import - but it means we can have a look at how it would turn out. Yeah, Ben told me that already! What do people think in general? +1's: * We'd be fully on Apache controlled hardware Some other advantages: - it's what some new users expect (I've had some small complaints over time about not finding it / needing another account on a different JIRA) - the subversion commits tab would work again - takes the load of Ben Codehaus :) -1's: * Since a lot of the issues end up being actually issues in a lower layer (most of which if not ASF hosted live/lived @ codehaus) or an upper layer (i.e. one of the mojo plugins) we'd loose the ability to move those issues to the correct project and instead we'd have to create a new tracking issue on the root cause project's jira I don't see that that's a big issue. * What we have works, if it ain't broke don't fix it That's a pretty powerful one :) Once we have enough comments/feedback (I'm willing to give a week or two), I'll put the options to the Maven PMC who will ultimately EITHER make a decision OR delegate making a decision to all the Maven committers. -Stephen -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1131414 - in /maven/plugins/trunk/maven-changes-plugin: ./ src/main/java/org/apache/maven/plugin/jira/ src/site/apt/ src/site/apt/examples/
On 4 June 2011 21:04, Dennis Lundberg denn...@apache.org wrote: ... 2. Please use the following form for the commit messages: [issueId] issueSummary for example: [MCHANGES-254] Example doesn't work - spaces not allowed in statusIds and resolutionIds after a comma +1 It would be useful to have done this for r1131484 as well. I.e. instead of Fix typo from r1131414 . the log message could have been: [MCHANGES-254] Example doesn't work - spaces not allowed in statusIds and resolutionIds after a comma Fix bug introduced in r1131414 which would help tie it to the original issue. AFAIK, it's not too late to fix the log messages ... - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1131414 - in /maven/plugins/trunk/maven-changes-plugin: ./ src/main/java/org/apache/maven/plugin/jira/ src/site/apt/ src/site/apt/examples/
On 4 June 2011 22:02, Dennis Lundberg denn...@apache.org wrote: On 2011-06-04 22:44, Benson Margulies wrote: Dennis, Points taken. The web page with developer guidance does specifically give the syntax: [JIRA1, JIRA2, ...] comments Indeed they do. Looks like I have some site docs to update :) Unfortunately, it looks like Codehaus JIRA is not set up to add SVN log messages to issue comments, so the SVN ids need to be added manually to the issues. --benson On Sat, Jun 4, 2011 at 4:33 PM, Dennis Lundberg denn...@apache.org wrote: On 2011-06-04 22:16, sebb wrote: On 4 June 2011 21:04, Dennis Lundberg denn...@apache.org wrote: ... 2. Please use the following form for the commit messages: [issueId] issueSummary for example: [MCHANGES-254] Example doesn't work - spaces not allowed in statusIds and resolutionIds after a comma +1 It would be useful to have done this for r1131484 as well. I.e. instead of Fix typo from r1131414 . the log message could have been: [MCHANGES-254] Example doesn't work - spaces not allowed in statusIds and resolutionIds after a comma Fix bug introduced in r1131414 which would help tie it to the original issue. AFAIK, it's not too late to fix the log messages ... Right. I've fixed the commit message for r1131484 now. - 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1131414 - in /maven/plugins/trunk/maven-changes-plugin: ./ src/main/java/org/apache/maven/plugin/jira/ src/site/apt/ src/site/apt/examples/
Isn't in a lot easier if the Subversion commit details are available directly from the JIRA issue, either via the commit tab or as a comment? Also not difficult to do - just paste the commit header into the comment box when resolving the issue. 2011/6/5 Arnaud Héritier aherit...@gmail.com: There was an integration with fisheye and our SVN before but I think that Ben (aka Codehaus) had a lot of performances issues with it. I found an old maven repo in fisheye but it is no more updated that's probably why it isn't configured in the project : https://fisheye.codehaus.org/changelog/maven/repository/maven We can discuss with Ben to see if we can fix it. On Sun, Jun 5, 2011 at 1:48 AM, Benson Margulies bimargul...@gmail.comwrote: I have been. Did I miss one? This is generally a job for fisheye, after all. On Sat, Jun 4, 2011 at 7:45 PM, sebb seb...@gmail.com wrote: On 4 June 2011 22:02, Dennis Lundberg denn...@apache.org wrote: On 2011-06-04 22:44, Benson Margulies wrote: Dennis, Points taken. The web page with developer guidance does specifically give the syntax: [JIRA1, JIRA2, ...] comments Indeed they do. Looks like I have some site docs to update :) Unfortunately, it looks like Codehaus JIRA is not set up to add SVN log messages to issue comments, so the SVN ids need to be added manually to the issues. --benson On Sat, Jun 4, 2011 at 4:33 PM, Dennis Lundberg denn...@apache.org wrote: On 2011-06-04 22:16, sebb wrote: On 4 June 2011 21:04, Dennis Lundberg denn...@apache.org wrote: ... 2. Please use the following form for the commit messages: [issueId] issueSummary for example: [MCHANGES-254] Example doesn't work - spaces not allowed in statusIds and resolutionIds after a comma +1 It would be useful to have done this for r1131484 as well. I.e. instead of Fix typo from r1131414 . the log message could have been: [MCHANGES-254] Example doesn't work - spaces not allowed in statusIds and resolutionIds after a comma Fix bug introduced in r1131414 which would help tie it to the original issue. AFAIK, it's not too late to fix the log messages ... Right. I've fixed the commit message for r1131484 now. - 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 - 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 - 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: JIRA versus svn
Thanks! On 5 June 2011 17:15, Benson Margulies bimargul...@gmail.com wrote: I've pasted all the checkin comments from my activities this weekend into their respective jira. - 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: r1131414 - in /maven/plugins/trunk/maven-changes-plugin: ./ src/main/java/org/apache/maven/plugin/jira/ src/site/apt/ src/site/apt/examples/
On 6 June 2011 09:23, Dennis Lundberg denn...@apache.org wrote: On 2011-06-05 01:45, sebb wrote: On 4 June 2011 22:02, Dennis Lundberg denn...@apache.org wrote: On 2011-06-04 22:44, Benson Margulies wrote: Dennis, Points taken. The web page with developer guidance does specifically give the syntax: [JIRA1, JIRA2, ...] comments Indeed they do. Looks like I have some site docs to update :) Unfortunately, it looks like Codehaus JIRA is not set up to add SVN log messages to issue comments, so the SVN ids need to be added manually to the issues. Yes, I keep this snippet on my desktop and copy/paste it into JIRA when resolving an issue: Fixed in [r1129889|http://svn.apache.org/viewvc?view=revisionrevision=1129889]. Just remember to change the revision number. Why not pick up the details from the SVN log message? You can then include the list of files as well. For example: URL: http://svn.apache.org/viewvc?rev=1131414view=rev Log: [MCHANGES-254, MCHANGES-253] add more calls to trim, fix doc. Also fix some warnings in site generation. Modified: maven/plugins/trunk/maven-changes-plugin/pom.xml maven/plugins/trunk/maven-changes-plugin/src/main/java/org/apache/maven/plugin/jira/AbstractJiraDownloader.java maven/plugins/trunk/maven-changes-plugin/src/main/java/org/apache/maven/plugin/jira/JiraXML.java maven/plugins/trunk/maven-changes-plugin/src/site/apt/examples/customizing-jira-report.apt.vm maven/plugins/trunk/maven-changes-plugin/src/site/apt/usage.apt.vm --benson On Sat, Jun 4, 2011 at 4:33 PM, Dennis Lundberg denn...@apache.org wrote: On 2011-06-04 22:16, sebb wrote: On 4 June 2011 21:04, Dennis Lundberg denn...@apache.org wrote: ... 2. Please use the following form for the commit messages: [issueId] issueSummary for example: [MCHANGES-254] Example doesn't work - spaces not allowed in statusIds and resolutionIds after a comma +1 It would be useful to have done this for r1131484 as well. I.e. instead of Fix typo from r1131414 . the log message could have been: [MCHANGES-254] Example doesn't work - spaces not allowed in statusIds and resolutionIds after a comma Fix bug introduced in r1131414 which would help tie it to the original issue. AFAIK, it's not too late to fix the log messages ... Right. I've fixed the commit message for r1131484 now. - 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 - 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: The JIRA chocolate box
On 19 June 2011 11:52, Dennis Lundberg denn...@apache.org wrote: On 2011-06-19 00:30, Benson Margulies wrote: I just looked at the 'blocker' issues. We have a variety of very old JIRAs here. None of the ones I looked at have a self-contained test case that would can be downloaded, run, and converted to an integration test, etc. This is one of the major obstacles we have at the Maven project. The sheer amount of old and sometimes really old issues in JIRA. For the last couple of years I've pinged reporters of new issues straight away for test cases, if none was attached to a new issue. But as you say there are lots of old ones that are practically impossible to resolve without some kind of test case. Maybe we should plan a JIRA cleanup day? Let's find a date where some of us on the dev team can work together to clean up old issues. We announce that together with your proposed letter to the users list as well. What's the policy? My temptation would be to comment on them asking if the OP is still interested (in some cases, 5 years later), and, if so, can they come up with a repeatable test case, and if not close as not a real bug. I've done this kind of thing for plugins in the past. For those I have opted to close the issue as Incomplete, because it lacks a reproducible test case. +1 This will make it easier to find later if necessary. I think it's vital that the resolution distinguish such cases from fixed bugs and non-bugs. I don't mind in some cases doing work to build a test case, but to go to all this trouble for a bug that was opened about maven 2.0.x, where it may not be that easy to reconstruct the critical components of the problem, seems a dubious use of time. Agreed. - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: svn commit: r1131500 - in /maven/pom/trunk/asf: pom.xml src/ src/site/ src/site/apt/ src/site/apt/index.apt src/site/site.xml
May I make a plea for the ASF POM to include a link to the documentation in the comments? Also, maybe someone can fix the very long comment line starting with: As of Version 6, The description could be wrapped as well. On 27 June 2011 21:42, Benson Margulies bimargul...@gmail.com wrote: It occurs to me that the main pom could include a profile to run the site pom via the invoker. On Mon, Jun 27, 2011 at 4:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: option 1 seems to be controversial option 2, with site-pom.xml as suggested by Jörg, with specific siteDirectory site plugin configuration (to avoid site.xml problem like pom.xml), seems pretty good option 3, [1], doesn't seem accessible in the short term any objection to go with option 2? Regards, Hervé [1] http://mail-archives.apache.org/mod_mbox/maven- dev/201106.mbox/%3CBANLkTim7idTDmg=_kx3h1bsmdnqbxk4...@mail.gmail.com%3E Le lundi 27 juin 2011, Benson Margulies a écrit : Option 1: go ahead and put a full configuration in this POM, and then make sure that all of the things that use it really do over-ride it. Option 2: Give it a parent or child: create a project with a site just to document and aggregate this, with enough SEO to catch googles. Option 3: take up my elaborate suggestion in the mixin thread. On Sun, Jun 26, 2011 at 4:02 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Now the question is: where do we put ASF pom documentation? sharing a few thoughts: 1. in the project itself? need to find a way to get its publication done without tainting the pom 2. in the Maven site [1], in a dedicated directory 3. at the top of pom svn [2]: the main difference I see from Maven site is that we can configure project information specifically (issue tracking especially), create dedicated menu any thought? Regards, Hervé [1] http://svn.apache.org/viewvc/maven/site/trunk/ [2] http://svn.apache.org/viewvc/maven/pom/trunk/ - 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 - 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: r1131500 - in /maven/pom/trunk/asf: pom.xml src/ src/site/ src/site/apt/ src/site/apt/index.apt src/site/site.xml
On 28 June 2011 15:40, Benson Margulies bimargul...@gmail.com wrote: Sebb, I think that you are pointing at the dilemma at the center of this. Anything like this that we put into the top pom is inherited unless overriden, and people are skittish about accidently making everything part of the Maven project. Where would you propose that we put a link to that it would help? In a comment near the top of the file. -benson On Mon, Jun 27, 2011 at 6:40 PM, sebb seb...@gmail.com wrote: May I make a plea for the ASF POM to include a link to the documentation in the comments? Also, maybe someone can fix the very long comment line starting with: As of Version 6, The description could be wrapped as well. On 27 June 2011 21:42, Benson Margulies bimargul...@gmail.com wrote: It occurs to me that the main pom could include a profile to run the site pom via the invoker. On Mon, Jun 27, 2011 at 4:36 PM, Hervé BOUTEMY herve.bout...@free.fr wrote: option 1 seems to be controversial option 2, with site-pom.xml as suggested by Jörg, with specific siteDirectory site plugin configuration (to avoid site.xml problem like pom.xml), seems pretty good option 3, [1], doesn't seem accessible in the short term any objection to go with option 2? Regards, Hervé [1] http://mail-archives.apache.org/mod_mbox/maven- dev/201106.mbox/%3CBANLkTim7idTDmg=_kx3h1bsmdnqbxk4...@mail.gmail.com%3E Le lundi 27 juin 2011, Benson Margulies a écrit : Option 1: go ahead and put a full configuration in this POM, and then make sure that all of the things that use it really do over-ride it. Option 2: Give it a parent or child: create a project with a site just to document and aggregate this, with enough SEO to catch googles. Option 3: take up my elaborate suggestion in the mixin thread. On Sun, Jun 26, 2011 at 4:02 AM, Hervé BOUTEMY herve.bout...@free.fr wrote: Now the question is: where do we put ASF pom documentation? sharing a few thoughts: 1. in the project itself? need to find a way to get its publication done without tainting the pom 2. in the Maven site [1], in a dedicated directory 3. at the top of pom svn [2]: the main difference I see from Maven site is that we can configure project information specifically (issue tracking especially), create dedicated menu any thought? Regards, Hervé [1] http://svn.apache.org/viewvc/maven/site/trunk/ [2] http://svn.apache.org/viewvc/maven/pom/trunk/ - 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 - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Where to report bugs against apache jar resource bundle?
Looked around; cannot find out where to report bugs in the apache jar resource bundle. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Maven Release Plugin 2.2.2 Released
On 17 December 2011 01:46, Stephen Connolly steph...@apache.org wrote: The Maven team is pleased to announce the release of the Maven XXX Plugin, version Y.Z X, Y Z? This plugin is used to release a project with Maven, saving a lot of repetitive, manual work. Releasing a project is made in two steps: prepare and perform. http://maven.apache.org/plugins/maven-release-plugin/ You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-release-plugin/artifactId version2.2.2/version /plugin Release Notes - Maven 2.x Release Plugin - Version 2.2.2 ** Bug * [MRELEASE-354] - Versions defined in profiles are not updated * [MRELEASE-454] - The Release-Plugin does not rewrite dependencies in the DependencyManagement with scope import * [MRELEASE-577] - release:prepare does not pass argument --settings with current settings.xml to inner maven ** Improvement * [MRELEASE-708] - upgrade to last scm 1.6 to integrate new scm provider mks integrity ** New Feature * [MRELEASE-467] - Release preparation should update version of plugin dependencies Enjoy, -The 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: [ANN] Maven Checkstyle Plugin 2.9 Released
On 12 February 2012 16:33, Dennis Lundberg denn...@apache.org wrote: The Maven team is pleased to announce the release of the Maven Checkstyle Plugin, version 2.9 Generates a report on violations of code style and optionally fails the build if violations are detected. http://maven.apache.org/plugins/maven-checkstyle-plugin You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-checkstyle-plugin/artifactId version2.9/version /plugin Release Notes - Maven Checkstyle Plugin - Version 2.9 Bug * [MCHECKSTYLE-170] Test errors and failures on Windows * [MCHECKSTYLE-168] checkstyle-aggregate give a wrong file count * [MCHECKSTYLE-167] Unconfigured checkstyle plugin duplicates entries in aggregated report Unfortunately 2.9 does *not* actually fix the above bug - mvn site still runs checkstyle aggregate for projects without modules. * [MCHECKSTYLE-164] Multimodule Configuration example does not show how to configure build-tools pom * [MCHECKSTYLE-152] encoding property in maven plugin is never set correctly to charset property of the checkstyle itself. * [MCHECKSTYLE-146] mvn checkstyle:checkstyle KO, Unable to find the mojo, org/apache/maven/doxia/logging/Log * [MCHECKSTYLE-145] maven-checkstyle-plugin 2.6 SinkFactory WARNING Improvement * [MCHECKSTYLE-165] Upgrade to checkstyle 5.5 Enjoy, -The 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
[dist] maven_pre_svnpubsub
The DIST directory currently contains the following Maven directories: drwxrwsr-x 7 svnwc svnwc 8 Sep 20 10:59 maven drwxrwsr-x 4 apbackup maven 5 Sep 1 17:32 maven_pre_svnpubsub Is the maven_pre_svnpubsub directory still needed? Is it referenced in any download pages? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [ANN] Maven Surefire Plugin 2.13 Released
On 28 December 2012 01:24, Kristian Rosenvold krosenv...@apache.org wrote: The Maven team is pleased to announce the release of the Maven Surefire Plugin, version 2.13 This release includes the maven-surefire-plugin, which executes the unit tests of an application, the maven-surefire-report-plugin, which parses surefire/failsafe test results and renders them to DOXIA creating the web interface version of the test results, as well as the maven-failsafe-plugin, which executes the integration tests of an application. Notable changes are; A) Much improved summary of what went wrong when tests failed B) Reusable forks supported for parallel builds; reuserForks=true s/reuserForks/reuseForks/ ?? gives forkMode=always on stereoids C) Stack trace trimming now works for JUnit4.x. The itch you didn't know you had until it was scratched. D) Includes and excludes can be read form file. E) Nasty thread safey issue in parallel junit 4.x when class was annotated with @Ignore. You should specify the version in your project's plugin configuration: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-surefire-plugin/artifactId version2.13/version /plugin Release Notes - Maven Surefire - Version 2.13 ** Bug * [SUREFIRE-800] - redirectTestOutputToFile is not taken into account in all cases with JUnit47 provider * [SUREFIRE-842] - maven-failsafe-plugin V 2.12 conceils issue #TRUEZIP-227 * [SUREFIRE-892] - Surefire Report Plugin crashes on failsafe-summary.xml * [SUREFIRE-910] - Surefire 2.12.1 fails with The forked VM terminated without saying properly goodbye * [SUREFIRE-913] - forkMode always - RejectedExecutionException when 500 tests * [SUREFIRE-915] - runOrder=failedfirst runs new tests last * [SUREFIRE-916] - surefire.junit4.upgradecheck fails with ClassCastException: java.lang.Class cannot be cast to java.lang.String * [SUREFIRE-918] - Phase post-integration-test not executed when tests are timed out with option 'forkedProcessTimeoutInSeconds' * [SUREFIRE-920] - -Dmaven.test.failure.ignore=true isn't honored * [SUREFIRE-926] - Multiple Providers, last one overwrites status of first... * [SUREFIRE-930] - Regression - Failsafe does not execute TestCases * [SUREFIRE-931] - Surefire crashes if test depends on unknown group * [SUREFIRE-933] - forkMode onceperthread broken after fix for JUnit category filter with empty result * [SUREFIRE-937] - Test count intermittently incorrect with parallel junit provider * [SUREFIRE-939] - Class level @Ignore would create incorrect shared state for parallel junit tests * [SUREFIRE-940] - Maven-failsafe-plugin do not run the TestNG.xml specified * [SUREFIRE-942] - surefire + testng suite doesn't do anything ** Improvement * [SUREFIRE-561] - after running test, when tests fail, it's hard to the find the failure reason * [SUREFIRE-839] - If no tests are found that would match a given JUnit category, mvn test should not fail in multi-module project * [SUREFIRE-925] - All includes and excludes to be read from files * [SUREFIRE-927] - configFailurePolicy is not supported on Surefire plugin though it is supported on TestNG ant task * [SUREFIRE-932] - Improve or remove logging of TestNG configurator * [SUREFIRE-935] - Implement trimStackTrace for JUnit 4.x * [SUREFIRE-936] - Make it easier to see which tests fail ** New Feature * [SUREFIRE-751] - Support parallel/fork mode similar to http://maven-junit-plugin.kenai.com/ * [SUREFIRE-882] - Fork x parallel JVMs once ** Task * [SUREFIRE-924] - generate every Surefire artifact site in /surefire and redirect previous /plugins/maven-(surefire|failsafe|surefire-report)-plugin * [SUREFIRE-934] - Remove getLocatedClasses() and size() from TestsToRun 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
JavadocFixTool integration with Javadoc plugin?
I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JavadocFixTool integration with Javadoc plugin?
On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: JavadocFixTool integration with Javadoc plugin?
On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - 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
Re: JavadocFixTool integration with Javadoc plugin?
On 20 June 2013 13:08, sebb seb...@gmail.com wrote: On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, if you do change it, it would make sense to update the comments and the version string. There are a couple of resources that are not closed properly; one such means the original file is not deleted on Windows. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - 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
Re: JavadocFixTool integration with Javadoc plugin?
On 20 June 2013 13:21, Olivier Lamy ol...@apache.org wrote: 2013/6/20 sebb seb...@gmail.com: On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? it simply depends the phase you bind the plugin (per default it's not bind to any phase) But the point is that a separate plugin will have to be separately configured, probably several times. That's not a trivial job, and it's easy to overlook phases and locations of Javadoc. Whereas if the Javadoc plugin fixes any issues before it completes, the end user merely has to ensure they are using the new Javadoc plugin. That's much easier to do. The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - 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 -- 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
Re: JavadocFixTool integration with Javadoc plugin?
On 20 June 2013 14:20, Baptiste MATHUS bmat...@batmat.net wrote: I'm +1 with you on the fact that this code should be included after each javadoc goal. I guess they agree too, but I *think* this is just something Olivier and the Maven PMC cannot afford integrating this code into the maven-javadoc-plugin without being 200% sure this isn't going to be a license infringement. This is their 100% is enough. responsability not to drag the Apache foundation into such issues. Ok, but from all the comments I have seen the license is OK. We are wasting time and effort here. Cheers 2013/6/20 sebb seb...@gmail.com On 20 June 2013 13:21, Olivier Lamy ol...@apache.org wrote: 2013/6/20 sebb seb...@gmail.com: On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? it simply depends the phase you bind the plugin (per default it's not bind to any phase) But the point is that a separate plugin will have to be separately configured, probably several times. That's not a trivial job, and it's easy to overlook phases and locations of Javadoc. Whereas if the Javadoc plugin fixes any issues before it completes, the end user merely has to ensure they are using the new Javadoc plugin. That's much easier to do. The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - 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 -- Olivier Lamy Ecetera: http://ecetera.com.au http://twitter.com/olamy | http://linkedin.com/in/olamy
Re: JavadocFixTool integration with Javadoc plugin?
https://issues.apache.org/jira/browse/LEGAL-171 On 20 June 2013 15:35, Stuart McCulloch mccu...@gmail.com wrote: On 20 Jun 2013, at 15:19, sebb wrote: On 20 June 2013 14:20, Baptiste MATHUS bmat...@batmat.net wrote: I'm +1 with you on the fact that this code should be included after each javadoc goal. I guess they agree too, but I *think* this is just something Olivier and the Maven PMC cannot afford integrating this code into the maven-javadoc-plugin without being 200% sure this isn't going to be a license infringement. This is their 100% is enough. responsability not to drag the Apache foundation into such issues. Ok, but from all the comments I have seen the license is OK. IANAL, but there appears to be an export/field-of-use clause in that license: You agree to comply fully with export laws and regulations of the United States and any other applicable export laws (Export Laws) to assure that neither the Program nor any direct products thereof are: (1) exported, directly or indirectly, in violation of this Agreement or Export Laws; or (2) used for any purposes prohibited by the Export Laws, including, without limitation, nuclear, chemical, or biological weapons proliferation, or development of missile technology. so I think it would be best to run this past legal before committing We are wasting time and effort here. Cheers 2013/6/20 sebb seb...@gmail.com On 20 June 2013 13:21, Olivier Lamy ol...@apache.org wrote: 2013/6/20 sebb seb...@gmail.com: On 20 June 2013 12:15, Olivier Lamy ol...@apache.org wrote: See https://github.com/olamy/JavadocUpdaterTool I added a maven build and a mojo. IANAL so I don't know if we can integrate the source of JavadocFixTool.java in javadoc plugin ( https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) As far as I can tell, so long as the code is only used for the intended purpose then it's OK. However, I don't think your plugin fixes all instances of bad javadoc; certainly the instructions only solve the problem for site builds. What about javadoc jars? it simply depends the phase you bind the plugin (per default it's not bind to any phase) But the point is that a separate plugin will have to be separately configured, probably several times. That's not a trivial job, and it's easy to overlook phases and locations of Javadoc. Whereas if the Javadoc plugin fixes any issues before it completes, the end user merely has to ensure they are using the new Javadoc plugin. That's much easier to do. The Maven javadoc jar has lots of goals that occur in different phases; the only way to be sure to fix all the issues is to always run the tool after running Javadoc. 2013/6/20 sebb seb...@gmail.com: On 19 June 2013 22:40, Baptiste MATHUS bmat...@batmat.net wrote: Hi, I think the best way to track this is to file a JIRA ticket on http://jira.codehaus.org/browse/MJAVADOC Well OK, I can raise an enhancement request there too. Btw, we might be interested by https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java That looks exactly like the file that was released by Oracle; anyone can pick up the tool packaged as a jar from the Oracle web-site. On it's own, it does not help. Cheers 2013/6/19 sebb seb...@gmail.com I expect you have all see the news about the Javadoc javascript bug. It's going to take a long time for everyone to update their Java installations to Java 1.7 u25. Likewise for builds that need to use other Java versions, tweaking poms so Java 7 is used for Javadocs whilst still maintaining compatibility is a non-trivial task. Is there any interest in releasing a quick-fix version of the javadoc plugin that automatically runs the tool after Javadoc completes? The fix code is in Java, and can easily be directly called from the plugin (no need to start a new process). The license looks friendly so long as the code is only used for Javadoc fixups, and changes are allowed, which is just as well - There are a couple of bugs in the tool as currently released. It does not close all the resources; and failure to close the input file means it cannot delete the original input file on Windows; that needs to be fixed as it would not make sense to keep the old faulty file (even if it is now called index.html.orig). I can provide details of the fixes, but a decent IDE will probably warn about them anyway. It would be a great service to the Java community if this could be fast-tracked. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Baptiste Batmat MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor ! - To unsubscribe
Re: Maven assembly plugin throwing error
On 21 June 2013 04:00, Steve Goodwin sgood...@cfl.rr.com wrote: Hi, I am simply trying to create a .zip from some folders in an svn project. When I try to run this a maven build I get the following error: That's really a question for the Maven Users list. There are more subscribers to answer your question, and more to benefit from the answer. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Poposed Sandbox plugins - digest and gpg:signfiles
I've just been told about the Maven Sandbox, which seems like it might be a better location for two general purpose plugins that are currently being developed at Apache Commons. Digest The digest plugin is a simple plugin that can generate hashes (currently just MD5 and SHA1) for any files specified via includes/excludes (or on command-line). Although it's possible to use Antrun to create the hashes, it's a bit awkward to configure. The plugin could be extended to check digests as well, and of course to generate other digest types. I'm hoping it might be generally useful. Gpg-signfiles This is an extension of the Maven Gpg Plugin which can sign arbitrary files, not just ones attached to the project I'm hoping it might be merged with the existing Gpg plugin one day; having the code in the sandbox should make it easier for other Maven devs to help. I propose creating the following directories under https://svn.apache.org/repos/asf/maven/sandbox/trunk/plugins maven-digest-plugin maven-gpgsignfiles-plugin Any objections? 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? - 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
On 23 June 2013 01:00, Olivier Lamy ol...@apache.org wrote: 2013/6/23 sebb seb...@gmail.com: 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
Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1
On 24 June 2013 13:04, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Apache Maven Javadoc Plugin 2.9.1. This version contains the code to fix the javadoc security issue after the javadoc generation. We fixed 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843styleName=TextprojectId=11138Create=Create Staging repository: https://repository.apache.org/content/repositories/maven-062 Staging site: http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ SVN tag? KEYS file? Vote open for 72H [+1] [0] [-1] The parameter applyJavadocSecurityFix in the class AbstractJavadocMojo is documented as being @since 2.10. The Release Notes page on the site is empty. There's no NOTICE and LICENSE in SVN at the level of the plugin. The NOTICE file looks wrong to me. It has a spurious blank line at the start. The next line says: Maven Javadoc Plugin This should be Apache Maven Javadoc Plugin The index.html file in the javadoc jar appears to have the frame bug; certainly it does not contain a function validURL(url) line. Sorry, but I would have to vote -1 if mine were binding. Thanks, -- 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
Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1
On 24 June 2013 23:58, Olivier Lamy ol...@apache.org wrote: 2013/6/25 sebb seb...@gmail.com: On 24 June 2013 13:04, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Apache Maven Javadoc Plugin 2.9.1. This version contains the code to fix the javadoc security issue after the javadoc generation. We fixed 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843styleName=TextprojectId=11138Create=Create Staging repository: https://repository.apache.org/content/repositories/maven-062 Staging site: http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ SVN tag? It's a bit implicit if you know our sources tree Yes, but it helps to have the URL and especially the revision quoted in the e-mail. Tags are supposed to be immutable but frequently are not, so the revision is necessary. KEYS file? I believe it's available as most of ASF project at svn.a.o/repos/asf/$tlp/project/KEYS Please quote whatever KEYS file is listed on the source download page and/or ASF dist directory. It's important that reviewers can check that end-users have access to the keys they need to check downloads. Vote open for 72H [+1] [0] [-1] The parameter applyJavadocSecurityFix in the class AbstractJavadocMojo is documented as being @since 2.10. Argh good catch I will fix that The Release Notes page on the site is empty. ? There's no NOTICE and LICENSE in SVN at the level of the plugin. Those files are in the voted artifacts. The NOTICE file looks wrong to me. It has a spurious blank line at the start. The next line says: Maven Javadoc Plugin This should be Apache Maven Javadoc Plugin Easy to fix The index.html file in the javadoc jar appears to have the frame bug; certainly it does not contain a function validURL(url) line. Chicken and egg issue as I need the fix but I'm build the fix. Or just use Java 1.7.0_25 for the build and Java 1.6 for the compile/test. So this will be probably the last javadoc jar we publish :-). At least the most (public website has been generated with the fix). BTW I cancel the release. Sorry, but I would have to vote -1 if mine were binding. Thanks, -- 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 -- 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
Re: svn commit: r1496295 - /maven/plugins/trunk/maven-javadoc-plugin/pom.xml
On 25 June 2013 00:26, ol...@apache.org wrote: Author: olamy Date: Mon Jun 24 23:26:16 2013 New Revision: 1496295 URL: http://svn.apache.org/r1496295 Log: fix name Modified: maven/plugins/trunk/maven-javadoc-plugin/pom.xml Modified: maven/plugins/trunk/maven-javadoc-plugin/pom.xml URL: http://svn.apache.org/viewvc/maven/plugins/trunk/maven-javadoc-plugin/pom.xml?rev=1496295r1=1496294r2=1496295view=diff == --- maven/plugins/trunk/maven-javadoc-plugin/pom.xml (original) +++ maven/plugins/trunk/maven-javadoc-plugin/pom.xml Mon Jun 24 23:26:16 2013 @@ -33,7 +33,7 @@ under the License. version2.9.1-SNAPSHOT/version packagingmaven-plugin/packaging - nameMaven Javadoc Plugin/name + nameApache Maven Javadoc Plugin/name description The Maven Javadoc Plugin is a plugin that uses the javadoc tool for Here too please! generating javadocs for the specified project. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1 (take 2)
On 25 June 2013 02:48, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Apache Maven Javadoc Plugin 2.9.1. This version contains the code to fix the javadoc security issue after the javadoc generation. Since previous try I fix the @since for applying the javadoc security fix. We fixed 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843styleName=TextprojectId=11138Create=Create Staging repository: https://repository.apache.org/content/repositories/maven-066/ The NOTICE file still has a spurious blank line at the start; it should be removed before the next release candidate. Staging site: http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ The release notes page is empty, as before. Given that this release has a vital change in it, that is very unfortunate. SVN tag and revision? Without them, how can reviewers determine the provenance of the source files in the source release? KEYS file? How can we check the sigs? Vote open for 72H [+1] [0] [-1] Thanks, -- 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
Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1 (take 2)
On 25 June 2013 07:46, Ralph Goers ralph.go...@dslextreme.com wrote: KEYS file - http://svn.apache.org/repos/asf/maven/project/KEYS Thanks, the key id used for signing is in the file. Also the id is available from key servers. svn tag - http://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1 Thanks, but that is insufficient as the tag has been recreated several times. I think the last one was r1496317 If there is ever a question about how a certain file got into a release, it's vital to have traceability. The source archive agrees with the SVN tag, apart from some expected differences - e.g. DEPENDENCIES is only in the source archive +1 on the release however it is odd that the Release Notes page is empty. Please fix that on the actual site deploy. Ralph On Jun 24, 2013, at 7:15 PM, sebb wrote: On 25 June 2013 02:48, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Apache Maven Javadoc Plugin 2.9.1. This version contains the code to fix the javadoc security issue after the javadoc generation. Since previous try I fix the @since for applying the javadoc security fix. We fixed 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843styleName=TextprojectId=11138Create=Create Staging repository: https://repository.apache.org/content/repositories/maven-066/ The NOTICE file still has a spurious blank line at the start; it should be removed before the next release candidate. Staging site: http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ The release notes page is empty, as before. Given that this release has a vital change in it, that is very unfortunate. SVN tag and revision? Without them, how can reviewers determine the provenance of the source files in the source release? KEYS file? How can we check the sigs? Vote open for 72H [+1] [0] [-1] Thanks, -- 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
Sandbox - cannot deploy snapshot of maven-digest-plugin; access denied
I'd like to try deploying a snapshot of the new digest plugin but I get access denied errors. Any idea why that should be? I can deploy Common snapshots OK to the same repo; is there an ACL that only allows Maven committers to deploy snapshots. or is some other config needed? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Sandbox - cannot deploy snapshot of maven-digest-plugin; access denied
On 25 June 2013 11:49, Olivier Lamy ol...@apache.org wrote: 2013/6/25 sebb seb...@gmail.com: I'd like to try deploying a snapshot of the new digest plugin but I get access denied errors. Any idea why that should be? IMHO you need to be in the maven group. OK, NP. I can deploy Common snapshots OK to the same repo; is there an ACL that only allows Maven committers to deploy snapshots. or is some other config needed? I deployed the digest one. Thanks. If you fix the groupId and artifactId for the maven-gpgsignfiles-plugin, I can do it for you too. Ta. There's quite a lot of other stuff that needs fixing as well to replace the Commons references. I hope to get to it soon. - 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
Release process updates
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. 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
Re: Release process updates
On 25 June 2013 19:19, Ralph Goers ralph.go...@dslextreme.com wrote: Again I have to disagree. The release manager will send an email closing the prior release. At this point all the prior release artifacts are junk even if they still exist. At some point the release manager will delete the tag and rerun the release. At this point the tag is still junk to everyone else because they have no idea what the RM is doing - so they shouldn't be making assumptions about non-released tags. Once he sends the email though the tag will be valid. Sure having the revision number helps but unless the RM completely screws up the tag should be sufficient. The only way to know which version of the tag is relevant is to work out which tag happened to be present when the vote took place. Since SVN tags are not physically immutable, they must be identified with the revision. Why make a fuss over providing the info - which is readily available to the RM from the commit message - when it makes it so much easier in retrospect to know what was voted on. Also if there are several versions of a tag and vote threads - as happens frequently - it can be very difficult untangling which is which, as they can easily overlap in time if people have not caught up fully with their e-mail. It needs to be absolutely clear what reviewers are voting on, both at the time, and later on when memories have faded. Ralph On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote: Not really, no. The developer may have re-spun it again and be about to email again. You have no idea what you're looking at unless you know the revision. SVN will die off within a decade and this discussion will become critical. Better to figure out how to support proper techniques now, rather than wait until forced to. On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers ralph.go...@dslextreme.comwrote: I disagree that the revision is required. I know that the RM is going to recreate the tag with each release candidate. Therefore, so long as I refetch that tag for every release vote I can be confident that I am reviewing the release contents. Ralph On Jun 25, 2013, at 9:52 AM, 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. 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 - 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: Release process updates
It would be a lot better to use RC1 RC2 etc initially, and copy the successful tag to the GA tag. On 25 June 2013 19:38, Ralph Goers ralph.go...@dslextreme.com wrote: Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them. On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote: On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Again I have to disagree. The release manager will send an email closing the prior release. At this point all the prior release artifacts are junk even if they still exist. At some point the release manager will delete the tag and rerun the release. That's a no-no IMO. Tags that have been voted on should never be deleted. Gary At this point the tag is still junk to everyone else because they have no idea what the RM is doing - so they shouldn't be making assumptions about non-released tags. Once he sends the email though the tag will be valid. Sure having the revision number helps but unless the RM completely screws up the tag should be sufficient. Ralph On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote: Not really, no. The developer may have re-spun it again and be about to email again. You have no idea what you're looking at unless you know the revision. SVN will die off within a decade and this discussion will become critical. Better to figure out how to support proper techniques now, rather than wait until forced to. On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers ralph.go...@dslextreme.com wrote: I disagree that the revision is required. I know that the RM is going to recreate the tag with each release candidate. Therefore, so long as I refetch that tag for every release vote I can be confident that I am reviewing the release contents. Ralph On Jun 25, 2013, at 9:52 AM, 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. 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 - 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 -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Editionhttp://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory - 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: Release process updates
On 25 June 2013 19:33, Hervé BOUTEMY herve.bout...@free.fr wrote: Le mardi 25 juin 2013 17:52:20 sebb a écrit : 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?) we use the release plugin, which does the release from a fresh checkout (FYI causing problems for people working in EU, since there is a delay between tag creation and content availability to subsequent checkout). I don't know any release from Maven project with unpredictable content: yes, such problem is unknown from Maven, because the release process tooling is consistent. If reviewers aren't provided with the SVN tag to do the checks, of course any such problems are likely to be unknown. Given this use of the release plugin, I don't see any problem with our release process (other than theory and over-generalization) Regards, Hervé - 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
org.apache.maven.plugin or org.apache.maven.plugins ?
Most plugins seem to be sub-packages of org.apache.maven.plugin; just a few use org.apache.maven.plugins (e.g. enforcer, shade). Is there a convention as to which to choose, or are the plugins that use plugins an anomaly? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release process updates
On 26 June 2013 01:04, Chris Graham chrisgw...@gmail.com wrote: -1 Except then the poms will point to the wrong place. Depends how the poms are updated. On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory garydgreg...@gmail.comwrote: On Tue, Jun 25, 2013 at 7:14 PM, sebb seb...@gmail.com wrote: It would be a lot better to use RC1 RC2 etc initially, and copy the successful tag to the GA tag. +1 ! :) Gary On 25 June 2013 19:38, Ralph Goers ralph.go...@dslextreme.com wrote: Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them. On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote: On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Again I have to disagree. The release manager will send an email closing the prior release. At this point all the prior release artifacts are junk even if they still exist. At some point the release manager will delete the tag and rerun the release. That's a no-no IMO. Tags that have been voted on should never be deleted. Gary At this point the tag is still junk to everyone else because they have no idea what the RM is doing - so they shouldn't be making assumptions about non-released tags. Once he sends the email though the tag will be valid. Sure having the revision number helps but unless the RM completely screws up the tag should be sufficient. Ralph On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote: Not really, no. The developer may have re-spun it again and be about to email again. You have no idea what you're looking at unless you know the revision. SVN will die off within a decade and this discussion will become critical. Better to figure out how to support proper techniques now, rather than wait until forced to. On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers ralph.go...@dslextreme.com wrote: I disagree that the revision is required. I know that the RM is going to recreate the tag with each release candidate. Therefore, so long as I refetch that tag for every release vote I can be confident that I am reviewing the release contents. Ralph On Jun 25, 2013, at 9:52 AM, 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. 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 - 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 -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition http://www.manning.com/bauer3/ JUnit in Action, Second Edition http://www.manning.com/tahchiev/ Spring Batch in Action http://www.manning.com/templier/ Blog
Re: Release process updates
On 26 June 2013 00:34, Chris Graham chrisgw...@gmail.com wrote: This appears to be a variant of the Do we reuse version numbers? discussion of recent times. That was resolved. Can we please not rehash this? -Chris On Wed, Jun 26, 2013 at 2:52 AM, sebb seb...@gmail.com 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. 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?) Ok, so you are not aware of the specifics of the maven release processes as implemented by the release plugin. So you're asking a generic question. Here is how the release plugin works: release:prepare is the goal that performs some tests, changes to a non snapshot version, creates the tag, bumps up the version no and commits the changes to the pom. release:perform simply checks out the newly created tag, into a new location (ie clean) and then calls mvn deploy. And if the mvn deploy fails for any reason? Is it necessary to re-run release:perform? And does that always create a fresh workspace? So for maven, yes, it is unknown for suprious files to creep in. -Chris - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Download links for source packages - where are they?
I could not find any download links for Maven source packages. As the ASF primary purpose is to release source, and that must be released via the mirror system, there ought to be download pages with links to the source package, sigs, hashes and KEYS file. Yes, there are source packages for some Maven plugins, but that is not the same as providing download pages. AFAIK every single other ASF project has download pages. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: org.apache.maven.plugin or org.apache.maven.plugins ?
On 26 June 2013 01:13, Olivier Lamy ol...@apache.org wrote: For historical reason this has changed etc.. Use org.apache.maven.plugins (same as groupId) OK thanks, I'll stick with plugins for the new ones then. 2013/6/26 sebb seb...@gmail.com: Most plugins seem to be sub-packages of org.apache.maven.plugin; just a few use org.apache.maven.plugins (e.g. enforcer, shade). Is there a convention as to which to choose, or are the plugins that use plugins an anomaly? - 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
Re: Release process updates
On 26 June 2013 01:25, Barrie Treloar baerr...@gmail.com wrote: And if the mvn deploy fails for any reason? We get this often enough with a crappy connection to our nexus servers. Is it necessary to re-run release:perform? release:perform may be at the stage where it has deleted the configuration file details, in which case you just revert to the manual steps that release:perform is automating for you. Which could result in spurious files in the workspace. People make mistakes. If its tagged everything correctly, and you build is fine - but the upload to the staging repository failed, then you can do this yourself. If this route is taken, there is no guarantee that the workspace is clean. People make mistakes. Or you can just re-spin the release process. No drama. And does that always create a fresh workspace? Yes. OK it might perhaps be possible to prove that this will never result in additional spurious files appearing in source archives. However there is also the possibility that vital files are missing from the source archive. For that to be detected, a comparison with the SVN tag is needed. - 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: Release process updates
On 25 June 2013 20:15, Uwe Schindler u...@thetaphi.de wrote: Hi, I agree with sebb. I am not a Maven committer, but the release revision is very important in the Lucene Project (where I am the chair). We have another workflow, working with revision number: - Release manager produces source and binary artifacts from a checkout of the current development brank (trunk aka 5.x or stable aka 4.x), publishes them on people.apache.org in a folder named http://people.apache.org/~use/staging-area/lucene-solr-X.Y-r1234567 - Release manager does *not* create an SVN tag at that time!!! The vote is on the revision and artifacts only! - We have automated release testing (we check for spurious files in the archives by our python-based smoke tester). This checks things like all JARs have correct META-INF, no license files are missing, NOTICE files are referring to *all* external dependencies, LICENSE.txt is in root folder of TGZ, line feeds are unix-only, release binary was compiled with the *minimum* JDK version (what we use as -source/-target for javac), and so on. - Once vote passes, release manager tags the exact revision number as used above in the folder name (svn cp -r1234567 ...) and releases the artifacts. By that there is no need to recreate tags, because the tag is only created when the stuff was actually released. This is a slightly different workflow, but is proven to work since years now. Since the release process uses the revision number, it does not particularly matter that the code is still in trunk; after all trunk and tags are just names. I find it easier to work with a named tag (perhaps because I am used to it), but so long as the SVN source is uniquely identified and used to compare against the source contents it does not matter what the name is. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: sebb [mailto:seb...@gmail.com] Sent: Tuesday, June 25, 2013 6:52 PM To: dev@maven.apache.org Subject: Release process updates 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. 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 - 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: Release process updates
On 26 June 2013 01:43, Chris Graham chrisgw...@gmail.com wrote: On Wed, Jun 26, 2013 at 10:36 AM, sebb seb...@gmail.com wrote: However there is also the possibility that vital files are missing from the source archive. For that to be detected, a comparison with the SVN tag is needed. How? Given the source archive is built from the checked out tag? AIUI the source archive is build using the assembly descriptor; not everything in the workspace is bundled into the archive. Please go and run some releases and you'll see how the process works. That way you will be able to ask some specific questions rather than some generic ones based upon a lack of understanding of the existing processes. I am basing my responses on what has been said in this thread. -Chris - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release process updates
On 26 June 2013 01:41, Olivier Lamy ol...@apache.org wrote: correct. In case of failure during deploy: * cd target/checkout mvn clean deploy -Papache-release or * export/checkout the tag mvn clean deploy -Papache-release Neither of those guarantee that the workspace agrees with the tag. Only by checking out the tag into a fresh workspace can you hope to guarantee that. 2013/6/26 Barrie Treloar baerr...@gmail.com: And if the mvn deploy fails for any reason? We get this often enough with a crappy connection to our nexus servers. Is it necessary to re-run release:perform? release:perform may be at the stage where it has deleted the configuration file details, in which case you just revert to the manual steps that release:perform is automating for you. If its tagged everything correctly, and you build is fine - but the upload to the staging repository failed, then you can do this yourself. Or you can just re-spin the release process. No drama. And does that always create a fresh workspace? Yes. - 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
Re: Download links for source packages - where are they?
On 26 June 2013 02:14, Barrie Treloar baerr...@gmail.com wrote: On 26 June 2013 09:47, sebb seb...@gmail.com wrote: I could not find any download links for Maven source packages. As the ASF primary purpose is to release source, and that must be released via the mirror system, there ought to be download pages with links to the source package, sigs, hashes and KEYS file. Yes, there are source packages for some Maven plugins, but that is not the same as providing download pages. AFAIK every single other ASF project has download pages. As a PMC member, I welcome scrutiny that we are following the designated procedures. Apologies for the length, I had to do some digging around to actually remind myself of what we are meant to do. According to http://www.apache.org/dev/release.html http://www.apache.org/dev/release.html#where-do-releases-go Where do releases go? A release isn't 'released' until the contents are in the project's distribution directory, which is a subdirectory of www.apache.org/dist/. In addition to the distribution directory, project that use Maven or a related build tool sometimes place their releases on repository.apache.org beside some convenience binaries. The distribution directory is required, while the repository system is an optional convenience. And http://www.apache.org/dev/release.html#what-must-every-release-contain What Must Every ASF Release Contain? Every ASF release must contain a source package, which must be sufficient for a user to build and test the release provided they have access to the appropriate platform and tools. The source package must be cryptographically signed by the Release Manager with a detached signature; and that package together with its signature must be tested prior to voting +1 for release. Folks who vote +1 for release may offer their own cryptographic signature to be concatenated with the detached signature file (at the Release Manager's discretion) prior to release. Note that the PMC is responsible for all artifacts in their distribution directory, which is a subdirectory of www.apache.org/dist/ ; and all artifacts placed in their directory must be signed by a committer, preferably by a PMC member. It is also necessary for the PMC to ensure that the source package is sufficient to build any binary artifacts associated with the release. Every ASF release must comply with ASF licensing policy. This requirement is of utmost importance and an audit should be performed before any full release is created. In particular, every artifact distributed must contain only appropriately licensed code. More information can be found in the foundation website and in the release licensing FAQ. And http://www.apache.org/dev/release.html#release-announcements How Should Releases Be Announced? Please ensure that you wait at least 24 hours after uploading a new release before updating the project download page and sending the announcement email(s). This is so that mirrors have sufficient time to catch up. (For time-critical security releases, the download pages script supports bypassing this requirement.) As far as I can tell there is no official policy requiring projects to provide a download page. It is just a convenience to end users to give them a direct download link. The ASF documentation clearly defines where distributions must be placed. Since you want people to use your project it makes sense to create a download page to make it easy for them. For Maven itself there are clearly defined download links from the main entry point http://maven.apache.org. For plugins I dont think it makes any sense to provide direct download links to sources. I checked http://www.apache.org/dev/release.html#maven-artifacts, which links to http://www.apache.org/dev/publishing-maven-artifacts.html doesn't provide any more guidance here either. So why doesn't it make sense to provide direct download links? Because it is Maven that is the consumer of artifacts rather than the end users. And an end user is not likely to be building a plugin from source and then installing it into their local Maven cache, it is much easier to get Maven to download the binaries and use them that way. The only reason I can think of a user wanting access to the source is so they can make modifications, and if they dont know about the ASF distribution pages, we give them the source repository link, e.g. http://maven.apache.org/plugins/maven-compiler-plugin/source-repository.html, on the automatically generated web pages. To me this is better as they can then create patches. Does that make sense? The point is that the ASF release source, and it must be provided for download via the ASF mirrors. See: http://www.apache.org/dev/release.html#host-GA If you don't point users to the source, I don't see how you can claim it has been properly released
Re: Release process updates
On 26 June 2013 02:18, Barrie Treloar baerr...@gmail.com wrote: On 26 June 2013 10:19, sebb seb...@gmail.com wrote: On 26 June 2013 01:41, Olivier Lamy ol...@apache.org wrote: correct. In case of failure during deploy: * cd target/checkout mvn clean deploy -Papache-release or * export/checkout the tag mvn clean deploy -Papache-release Neither of those guarantee that the workspace agrees with the tag. Only by checking out the tag into a fresh workspace can you hope to guarantee that. Then replace cd target/checkout mvn clean deploy -Papache-release with delete target/checkout svn co blah to target/checkout mvn clean deploy -Papache-release Since it was mvn release:perform that created target/checkout in the first place and no one has made any changes in that directory, cd You cannot know that for sure. People make mistakes; try things out, get distracted, forget that they changed something. target/checkout has the same results. Not guaranteed. - 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: Release process updates
I meant: if the pom is created with the correct final URLs in the first place, it won't have to be changed. It might need a tweak to the appropriate plugin, but it's not impossible to achieve. The same process would work with the system used by Lucene. On 26 June 2013 06:48, Hervé BOUTEMY herve.bout...@free.fr wrote: the jar content isn't updated: so you have jar artifacts inconsistent with svn Le mercredi 26 juin 2013 01:08:59 sebb a écrit : On 26 June 2013 01:04, Chris Graham chrisgw...@gmail.com wrote: -1 Except then the poms will point to the wrong place. Depends how the poms are updated. On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory garydgreg...@gmail.comwrote: On Tue, Jun 25, 2013 at 7:14 PM, sebb seb...@gmail.com wrote: It would be a lot better to use RC1 RC2 etc initially, and copy the successful tag to the GA tag. +1 ! :) Gary On 25 June 2013 19:38, Ralph Goers ralph.go...@dslextreme.com wrote: Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them. On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote: On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Again I have to disagree. The release manager will send an email closing the prior release. At this point all the prior release artifacts are junk even if they still exist. At some point the release manager will delete the tag and rerun the release. That's a no-no IMO. Tags that have been voted on should never be deleted. Gary At this point the tag is still junk to everyone else because they have no idea what the RM is doing - so they shouldn't be making assumptions about non-released tags. Once he sends the email though the tag will be valid. Sure having the revision number helps but unless the RM completely screws up the tag should be sufficient. Ralph On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote: Not really, no. The developer may have re-spun it again and be about to email again. You have no idea what you're looking at unless you know the revision. SVN will die off within a decade and this discussion will become critical. Better to figure out how to support proper techniques now, rather than wait until forced to. On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers ralph.go...@dslextreme.com wrote: I disagree that the revision is required. I know that the RM is going to recreate the tag with each release candidate. Therefore, so long as I refetch that tag for every release vote I can be confident that I am reviewing the release contents. Ralph On Jun 25, 2013, at 9:52 AM, 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. 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
Re: Download links for source packages - where are they?
On 26 June 2013 02:48, Barrie Treloar baerr...@gmail.com wrote: On 26 June 2013 10:48, sebb seb...@gmail.com wrote: The point is that the ASF release source, and it must be provided for download via the ASF mirrors. See: http://www.apache.org/dev/release.html#host-GA If you don't point users to the source, I don't see how you can claim it has been properly released. Which part of http://www.apache.org/dev/release.html#host-GA do you think we are violating? The spirit, if not the exact wording. Maybe the doc needs tweaking. Releases are available via http://archive.apache.org/dist/maven/plugins/ We meet Project download pages must link to the mirrors for the Maven Core Project - but not the plugins. I can find no documentation that says you *must* provide a download page. Just that if there is a download page it must point to the mirrors. Howewer the ASF releases source. If you don't provide a download link to the source how are users supposed to find it? I agree that most people are not going to want to download the original source. But that does not mean it should be left unlinked. - 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: Release process updates
On 26 June 2013 02:59, Barrie Treloar baerr...@gmail.com wrote: Then replace cd target/checkout mvn clean deploy -Papache-release with delete target/checkout svn co blah to target/checkout mvn clean deploy -Papache-release Since it was mvn release:perform that created target/checkout in the first place and no one has made any changes in that directory, cd You cannot know that for sure. People make mistakes; try things out, get distracted, forget that they changed something. target/checkout has the same results. Not guaranteed. In the end that does not matter. As long as the tag and the source release can be verified. Which is why the revision is needed in the vote mail. See http://www.apache.org/dev/release.html#owned-controlled-hardware, which links to https://svn.apache.org/repos/private/committers/tools/releases/compare_dirs.pl as a helper script. Yes, I often use that when reviewing releases to compare archives in different formats (it's not unknown for those to disagree by more than just EOL). AFAIK at present the script cannot be used to compare SCM with source archive, as there are files legitimately omitted from the source release (e.g. doap). In some cases there are additional generated files in the source archive (e.g. DEPENDENCIES). The ASF release process does not help to ensure the release is useful, merely that it meets the legal obligations of the foundation. Exactly my point. - 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: Release process updates
On 26 June 2013 10:56, Chris Graham chrisgw...@gmail.com wrote: On Wed, Jun 26, 2013 at 7:06 PM, sebb seb...@gmail.com wrote: I meant: if the pom is created with the correct final URLs in the first place, it won't have to be changed. They are. If you'd used the release plugin, then you would have seen this. I was responding to this: On 26 June 2013 01:04, Chris Graham chrisgw...@gmail.com wrote: -1 Except then the poms will point to the wrong place. but maybe I misunderstood. It might need a tweak to the appropriate plugin, but it's not impossible to achieve. You've not clearly stated what it is that you actually intend to achieve. I thought I stated that clearly in my original post at the start of this thread. The same process would work with the system used by Lucene. No, it wouldn't. From my reading of that email, there appeared to be far more manual steps involved, and probably a far larger time window involved as well. But I'd have to grok it a little more to be sure. On 26 June 2013 06:48, Hervé BOUTEMY herve.bout...@free.fr wrote: the jar content isn't updated: so you have jar artifacts inconsistent with svn Le mercredi 26 juin 2013 01:08:59 sebb a écrit : On 26 June 2013 01:04, Chris Graham chrisgw...@gmail.com wrote: -1 Except then the poms will point to the wrong place. Depends how the poms are updated. On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory garydgreg...@gmail.comwrote: On Tue, Jun 25, 2013 at 7:14 PM, sebb seb...@gmail.com wrote: It would be a lot better to use RC1 RC2 etc initially, and copy the successful tag to the GA tag. +1 ! :) Gary On 25 June 2013 19:38, Ralph Goers ralph.go...@dslextreme.com wrote: Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them. On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote: On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Again I have to disagree. The release manager will send an email closing the prior release. At this point all the prior release artifacts are junk even if they still exist. At some point the release manager will delete the tag and rerun the release. That's a no-no IMO. Tags that have been voted on should never be deleted. Gary At this point the tag is still junk to everyone else because they have no idea what the RM is doing - so they shouldn't be making assumptions about non-released tags. Once he sends the email though the tag will be valid. Sure having the revision number helps but unless the RM completely screws up the tag should be sufficient. Ralph On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote: Not really, no. The developer may have re-spun it again and be about to email again. You have no idea what you're looking at unless you know the revision. SVN will die off within a decade and this discussion will become critical. Better to figure out how to support proper techniques now, rather than wait until forced to. On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers ralph.go...@dslextreme.com wrote: I disagree that the revision is required. I know that the RM is going to recreate the tag with each release candidate. Therefore, so long as I refetch that tag for every release vote I can be confident that I am reviewing the release contents. Ralph On Jun 25, 2013, at 9:52 AM, 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. 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
Re: svn commit: r1497151 - /maven/site/trunk/content/xdoc/download.xml.vm
On 26 June 2013 23:54, ol...@apache.org wrote: Author: olamy Date: Wed Jun 26 22:54:24 2013 New Revision: 1497151 URL: http://svn.apache.org/r1497151 Log: add a link to sources to get a bit of peace (I hope at least for few days :-)) -1 wrong URL. Modified: maven/site/trunk/content/xdoc/download.xml.vm Modified: maven/site/trunk/content/xdoc/download.xml.vm URL: http://svn.apache.org/viewvc/maven/site/trunk/content/xdoc/download.xml.vm?rev=1497151r1=1497150r2=1497151view=diff == --- maven/site/trunk/content/xdoc/download.xml.vm (original) +++ maven/site/trunk/content/xdoc/download.xml.vm Wed Jun 26 22:54:24 2013 @@ -339,6 +339,9 @@ under the License. subsection name=Previous Releases pAll previous releases of Maven can be found in the a href=http://archive.apache.org/dist/maven/binaries/;archives/a./p /subsection + subsection name=All sources +pAll sources (plugins, shared librairies, scm, indexer etc..) can be downloaded from a href=http://www.us.apache.org/dist/maven/;http://www.us.apache.org/dist/maven//a/p What's with the .us. path name segment? The ASF site is mirrored between www.us.a.o and www.eu.a.o. Users should connect to www.apache.org, which will be geo-redirected to the appropriate website. Many ASF users have ISPs closer to the eu mirror than they do the us mirror. + /subsection subsection name=System Requirements p table - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release process updates
Yes, tags are cheap so can be kept until no longer useful. If there are a lot of stale tags it can get difficult to navigate the tags directory, so it makes sense to delete all but the successful tag once the vote has completed. There should be no need to keep failed tags once the vote is complete. That's what we tend to do on Commons and HttpComponents, except that the tags are immutable. We call them RC1, RC2 etc initially and copy (sometimes rename) to the GA tag on release. On 27 June 2013 01:35, Olivier Lamy ol...@apache.org wrote: Sounds a good idea for me (probably until someone else complain :-) ). And if that stop discussions and move people to working on code/fixing issues (i.e something very important for users) that will be great! 2013/6/27 Mirko Friedenhagen mfriedenha...@gmail.com: Hello there, when. respinning a release it would of help IMO instead of deleting the tag to rename it to e.g. maven-javadoc-plugin-2.9-rc1 using svn mv. By means of this you are able to easily diff between e.g. released 2.8 and the final 2.9 as well as between 2.9-rc1 and the final 2.9. Regards Mirko -- Sent from my mobile On Jun 26, 2013 12:14 PM, sebb seb...@gmail.com wrote: On 26 June 2013 10:56, Chris Graham chrisgw...@gmail.com wrote: On Wed, Jun 26, 2013 at 7:06 PM, sebb seb...@gmail.com wrote: I meant: if the pom is created with the correct final URLs in the first place, it won't have to be changed. They are. If you'd used the release plugin, then you would have seen this. I was responding to this: On 26 June 2013 01:04, Chris Graham chrisgw...@gmail.com wrote: -1 Except then the poms will point to the wrong place. but maybe I misunderstood. It might need a tweak to the appropriate plugin, but it's not impossible to achieve. You've not clearly stated what it is that you actually intend to achieve. I thought I stated that clearly in my original post at the start of this thread. The same process would work with the system used by Lucene. No, it wouldn't. From my reading of that email, there appeared to be far more manual steps involved, and probably a far larger time window involved as well. But I'd have to grok it a little more to be sure. On 26 June 2013 06:48, Hervé BOUTEMY herve.bout...@free.fr wrote: the jar content isn't updated: so you have jar artifacts inconsistent with svn Le mercredi 26 juin 2013 01:08:59 sebb a écrit : On 26 June 2013 01:04, Chris Graham chrisgw...@gmail.com wrote: -1 Except then the poms will point to the wrong place. Depends how the poms are updated. On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory garydgreg...@gmail.comwrote: On Tue, Jun 25, 2013 at 7:14 PM, sebb seb...@gmail.com wrote: It would be a lot better to use RC1 RC2 etc initially, and copy the successful tag to the GA tag. +1 ! :) Gary On 25 June 2013 19:38, Ralph Goers ralph.go...@dslextreme.com wrote: Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them. On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote: On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Again I have to disagree. The release manager will send an email closing the prior release. At this point all the prior release artifacts are junk even if they still exist. At some point the release manager will delete the tag and rerun the release. That's a no-no IMO. Tags that have been voted on should never be deleted. Gary At this point the tag is still junk to everyone else because they have no idea what the RM is doing - so they shouldn't be making assumptions about non-released tags. Once he sends the email though the tag will be valid. Sure having the revision number helps but unless the RM completely screws up the tag should be sufficient. Ralph On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote: Not really, no. The developer may have re-spun it again and be about to email again. You have no idea what you're looking at unless you know the revision. SVN will die off within a decade and this discussion will become critical. Better to figure out how to support proper techniques now, rather than wait until forced to. On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers ralph.go...@dslextreme.com wrote: I disagree that the revision is required. I know that the RM is going to recreate the tag with each release candidate
Re: [VOTE] Release Maven Enforcer version 1.3 (take 2)
On 25 June 2013 21:23, Robert Scholte rfscho...@apache.org wrote: Hi, We solved 15 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=19011 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11530status=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 enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_classworlds-1.1-alpha-2.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_container-default-1.0-alpha-9-stable-1.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_io-2.0.3.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_utils-1.0.4.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_utils-3.0.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer146_b-1.0.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer146_x-1.1.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer146_x-2.1.pom
Re: Release process updates
On 27 June 2013 15:05, Ralph Goers rgo...@apache.org wrote: I do not believe that can be done with the release plugins as the pom has to specify the same version as the tag. If you then rename the tag you would have to modify the poms in the tag, which makes the release invalid. Have you ever used the release plugin? If not, I would suggest you try it and offer up patches to change it instead of carrying on this discussion as it is unlikely maven is going to stop using the release plugin. This is straying further off the original topic. Whether people use the release plugin or some other method is not really relevant to the release vote itself. All the process that leads up to the vote is merely a means to trying to ensure that the release candidate as as good as possible. What matters is the vote - the public declaration that the RC has been reviewed and approved. Only a PMC-approved vote can get the legal protection of the ASF. The vote needs to be performed on input that can be readily checked by any reviewer. The vote has to be seen to be open and complete. The SVN (or GIT) coordinate is an essential part of the input, as it is the only practical way to check provenance of the files in the archives. Given that part of the Maven philisophy is to ensure that all plugin versions must be specified to ensure repeatable builds, I'm a bit surprised how much resistance there is to providing the specific source which was used as input to the build process. The only change that this requires to be made to the process is to add the revision number and tag name [1] to the release vote e-mail. Is that really too much to ask? [1] A revision on its one is insufficient as the ASF uses a shared SVN repo; the location within the tree is needed to be able to select the revelant portion of the tree. The tag name is one such way to provide the information. Ralph On Jun 25, 2013, at 4:14 PM, sebb seb...@gmail.com wrote: It would be a lot better to use RC1 RC2 etc initially, and copy the successful tag to the GA tag. On 25 June 2013 19:38, Ralph Goers ralph.go...@dslextreme.com wrote: Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed release vote instead of deleting them. On Jun 25, 2013, at 11:23 AM, Gary Gregory wrote: On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers ralph.go...@dslextreme.comwrote: Again I have to disagree. The release manager will send an email closing the prior release. At this point all the prior release artifacts are junk even if they still exist. At some point the release manager will delete the tag and rerun the release That's a no-no IMO. Tags that have been voted on should never be deleted. Gary At this point the tag is still junk to everyone else because they have no idea what the RM is doing - so they shouldn't be making assumptions about non-released tags. Once he sends the email though the tag will be valid. Sure having the revision number helps but unless the RM completely screws up the tag should be sufficient. Ralph On Jun 25, 2013, at 10:58 AM, Fred Cooke wrote: Not really, no. The developer may have re-spun it again and be about to email again. You have no idea what you're looking at unless you know the revision. SVN will die off within a decade and this discussion will become critical. Better to figure out how to support proper techniques now, rather than wait until forced to. On Tue, Jun 25, 2013 at 7:52 PM, Ralph Goers ralph.go...@dslextreme.com wrote: I disagree that the revision is required. I know that the RM is going to recreate the tag with each release candidate. Therefore, so long as I refetch that tag for every release vote I can be confident that I am reviewing the release contents. Ralph On Jun 25, 2013, at 9:52 AM, 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. 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
Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1 (take 2)
On 25 June 2013 12:20, Fred Cooke fred.co...@gmail.com wrote: Absolutely, sebb! This is what I've been saying all along. If I had more time I'd vote -1 to every attempted release that used or intended to use respun tags/artifacts without revisions and checksums. So here's one for this one until rectified properly -1! I quoted the tag and revision number earlier in this thread that I believe are the correct ones. It should really be done by the RM in the original e-mail, but at least the mail archives have the information now. On Tue, Jun 25, 2013 at 12:28 PM, sebb seb...@gmail.com wrote: On 25 June 2013 07:46, Ralph Goers ralph.go...@dslextreme.com wrote: KEYS file - http://svn.apache.org/repos/asf/maven/project/KEYS Thanks, the key id used for signing is in the file. Also the id is available from key servers. svn tag - http://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1 Thanks, but that is insufficient as the tag has been recreated several times. I think the last one was r1496317 If there is ever a question about how a certain file got into a release, it's vital to have traceability. The source archive agrees with the SVN tag, apart from some expected differences - e.g. DEPENDENCIES is only in the source archive +1 on the release however it is odd that the Release Notes page is empty. Please fix that on the actual site deploy. Ralph On Jun 24, 2013, at 7:15 PM, sebb wrote: On 25 June 2013 02:48, Olivier Lamy ol...@apache.org wrote: Hi, I'd like to release Apache Maven Javadoc Plugin 2.9.1. This version contains the code to fix the javadoc security issue after the javadoc generation. Since previous try I fix the @since for applying the javadoc security fix. We fixed 6 issues: https://jira.codehaus.org/secure/ReleaseNote.jspa?version=18843styleName=TextprojectId=11138Create=Create Staging repository: https://repository.apache.org/content/repositories/maven-066/ The NOTICE file still has a spurious blank line at the start; it should be removed before the next release candidate. Staging site: http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/ The release notes page is empty, as before. Given that this release has a vital change in it, that is very unfortunate. SVN tag and revision? Without them, how can reviewers determine the provenance of the source files in the source release? KEYS file? How can we check the sigs? Vote open for 72H [+1] [0] [-1] Thanks, -- 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
KEYS file has duplicate entry for F0E309FF - Vincent Massol
The file http://www.apache.org/dist/maven/KEYS has two entries for F0E309FF - Vincent Massol One of them should be deleted. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release process updates
The re-use of tags is a side-issue to this thread, though I'm glad to see some support for using immutable tags, whatever route is chosen Please start a new thread to continue that discussion. The vote e-mail must have the revision and tag name/trunk URL in it else it is not complete. Just as Maven insists on GAV - where V=version - a unique SVN coordinate requires the revision and the tree segment selector (e.g. tag). I don't know what Git needs - I suppose it may depend on whether multiple components are part of the same Git instance. But whatever - as it stands, the current vote e-mail is **incomplete**; it does not provide sufficient information for the candidate to be properly evaluated. The information needs to be present both for current and historical use. On 28 June 2013 10:09, Arnaud Héritier aherit...@gmail.com wrote: +1 to change our tags convention if it solves this issue by avoiding to reuse tag names to give a better visibility from where a release was done On Fri, Jun 28, 2013 at 7:58 AM, Kristian Rosenvold kristian.rosenv...@gmail.com wrote: This suggestion is much like what we came up with the last time we discussed this - about 3 weeks ago. This behaviour is simple to achieve without a single line of change; the release plugin already asks for a SCM tag name distinct from the version number. (we *could* add some kind of support for an explicit convention, we could even add a scm-lookup to auto-roll forward on subsequent takes). Now I've been trying to think if there's a sensible convention that could be established that would allow us to simply *keep* the tag name of the accepted version without re-pushing another tag after release (and, since the tag name can be etched into the pom of the released artifact, there should be no real reason for confusion). I've been thinking about a *tagging* convention along the lines of maven-xx-plugin-2.3.2#1, maven-xx-plugin-2.3.2#2, maven-xx-plugin-2.3.2#3... Effectively we would delete #1 and #2 and keep the #3 tag, since this vote passed on take 3. maven-xx-plugin-2.3.2#3 would also be the tagname in the pom of the released 2.3.2 version. This is mostly a policy change on tag naming, we could implement this without a line of code change. Since both svn and git essentially have flawed tag handling it makes sense to do a change like this. Kristian 2013/6/28 Ralph Goers ralph.go...@dslextreme.com: Can you provide the steps required to get the release plugin to work this way? Ralph On Jun 27, 2013, at 2:24 PM, Mirko Friedenhagen wrote: Hello, this seems to be the most popular discussion, so another 2 cents: - Today I read the man page of git-tag again. - It states very clearly you should never reuse tags, because unlike is the case with subversion, once a git tag is out in the wild (and pushing to git-wip is the jungle here), everyone who has fetched the tag would have to delete it *manually* from her copy, otherwise it will point to the wrong hash eternally. Another approach: - Always attach the rc-number to the tagname, e.g. maven-foo-2.16rc1, but *not* to the version. - *After* a successful vote create a copy of tag maven-foo-2.16rc1 as maven-foo-2.16 using the SCM directly. - The version stays enduser friendly and the tag in the pom points to the sources correctly. - Diffing between different RCs and the final versions is easy. - No one has to fiddle with invalid workspaces/clones. - For the release manager it is just one additional SCM call. Regards Mirko -- Sent from my mobile On Jun 27, 2013 4:42 PM, sebb seb...@gmail.com wrote: On 27 June 2013 15:05, Ralph Goers rgo...@apache.org wrote: I do not believe that can be done with the release plugins as the pom has to specify the same version as the tag. If you then rename the tag you would have to modify the poms in the tag, which makes the release invalid. Have you ever used the release plugin? If not, I would suggest you try it and offer up patches to change it instead of carrying on this discussion as it is unlikely maven is going to stop using the release plugin. This is straying further off the original topic. Whether people use the release plugin or some other method is not really relevant to the release vote itself. All the process that leads up to the vote is merely a means to trying to ensure that the release candidate as as good as possible. What matters is the vote - the public declaration that the RC has been reviewed and approved. Only a PMC-approved vote can get the legal protection of the ASF. The vote needs to be performed on input that can be readily checked by any reviewer. The vote has to be seen to be open and complete. The SVN (or GIT) coordinate is an essential part of the input, as it is the only practical way to check provenance of the files in the archives. Given that part of the Maven philisophy
Re: [VOTE] Release Maven Enforcer version 1.3 (take 2)
On 29 June 2013 11:47, Robert Scholte rfscho...@apache.org 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 seb...@gmail.com: On 25 June 2013 21:23, Robert Scholte rfscho...@apache.org wrote: Hi, We solved 15 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=19011 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11530status=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 enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_classworlds-1.1-alpha-2.pom enforcer-1.3/maven-enforcer-plugin/src/it/mrm/repository/menforcer138_container-default
Release process updates (try 2)
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: [VOTE] Apache 3.1.0
On 30 June 2013 20:00, Jason van Zyl ja...@tesla.io wrote: Here are the release bits for 3.1.0: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=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: [ANN] Apache Maven Enforcer Plugin 1.3 Released
On 30 June 2013 20:55, Robert Scholte rfscho...@apache.org 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: plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-enforcer-plugin/artifactId version1.3/version /plugin 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)
On 30 June 2013 21:04, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Sunday, 30 June 2013, sebb wrote: On 29 June 2013 11:47, Robert Scholte rfscho...@apache.org javascript:; 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 seb...@gmail.com: On 25 June 2013 21:23, Robert Scholte rfscho...@apache.org wrote: Hi, We solved 15 issues: http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530version=19011 There are still a couple of issues left in JIRA: http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=truepid=11530status=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)
On 30 June 2013 19:48, Fred Cooke fred.co...@gmail.com 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 seb...@gmail.com 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/
On 30 June 2013 21:25, rfscho...@apache.org 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/enforcer/enforcer-1.0.1-source-release.zip.md5
Unique Git coordinates (was: Release process updates (try 2))
On 30 June 2013 21:56, Fred Cooke fred.co...@gmail.com wrote: OK, so what is the Git command to download a copy of the sources that are part of the hash? git checkout hash 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
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 seb...@gmail.com wrote: On 30 June 2013 20:00, Jason van Zyl ja...@tesla.io wrote: Here are the release bits for 3.1.0: Release notes: https://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=10500version=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/
On 30 June 2013 22:36, Robert Scholte rfscho...@apache.org 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 seb...@gmail.com: On 30 June 2013 21:25, rfscho...@apache.org 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
Re: Unique Git coordinates (was: Release process updates (try 2))
On 30 June 2013 23:28, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On Sunday, 30 June 2013, sebb wrote: On 30 June 2013 21:56, Fred Cooke fred.co...@gmail.com javascript:; wrote: OK, so what is the Git command to download a copy of the sources that are part of the hash? git checkout hash 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)
On 30 June 2013 19:20, sebb seb...@gmail.com 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)
On 30 June 2013 23:32, Benson Margulies bimargul...@gmail.com 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 fred.co...@gmail.com wrote: OK, so what is the Git command to download a copy of the sources that are part of the hash? git checkout hash 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
Re: [VOTE] Apache 3.1.0
On 1 July 2013 03:56, Barrie Treloar baerr...@gmail.com wrote: On 1 July 2013 06:52, sebb seb...@gmail.com 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. The leading text enclosed in == was never part of the NOTICE file; AIUI it was added by Maven devs when producing the license plugin. Until fairly recently there was one ASF page which incorrectly said developed by instead of developed at; AFAIK there are now no incorrect references. 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
