+1
Sources at
https://repository.apache.org/content/repositories/maven-066/org/apache/maven/plugins/maven-javadoc-plugin/2.9.1/maven-javadoc-plugin-2.9.1-sources.jar,
based on r1496317
Kristian
-
To unsubscribe, e-mail:
KEYS file - http://svn.apache.org/repos/asf/maven/project/KEYS
svn tag -
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1
+1 on the release however it is odd that the Release Notes page is empty.
Ralph
On Jun 24, 2013, at 7:15 PM, sebb wrote:
On 25 June 2013
I will try to fix that. (as I remember changes plugin need to be
upgraded with new jira version)
So I can try redeploy the site with the fix.
2013/6/25 Ralph Goers ralph.go...@dslextreme.com:
KEYS file - http://svn.apache.org/repos/asf/maven/project/KEYS
svn tag -
fixed:
http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/jira-report.html
2013/6/25 Olivier Lamy ol...@apache.org:
I will try to fix that. (as I remember changes plugin need to be
upgraded with new jira version)
So I can try redeploy the site with the fix.
2013/6/25
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 -
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?
2013/6/25 sebb seb...@gmail.com:
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 -
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.
I can deploy Common snapshots OK to the same repo; is there an ACL
that only allows Maven
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
2013/6/25 sebb seb...@gmail.com:
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.
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!
On Tue, Jun 25, 2013 at 12:28 PM, sebb
The mission of the ASF is to release software as source, and to ensure
that the released source is available under the Apache Licence.
Before a release can be approved it must be voted on by the PMC.
The review process needs to establish that the proposed source release
meets those aims.
It's
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:
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
For record keeping purposes, the SVN revision + tag combo is better because
some RM's have inadvertently reused RC tags in the past. As Sebb pointed
out tags are mutable.
Gary
On Tue, Jun 25, 2013 at 1:52 PM, Ralph Goers ralph.go...@dslextreme.comwrote:
I disagree that the revision is
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
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
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
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
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi Thomas!
Am 15.06.2013 17:09, schrieb Thomas Koch:
In this case please add a warning against the json.org library and
all other software that includes the not evil clause:
http://wiki.debian.org/qa.debian.org/jsonevil
:) I want to develop a
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
I very much prefer your method, Uwe! There are lots of ways to do this
right. I hope one of those is chosen.
On Tue, Jun 25, 2013 at 9:15 PM, 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
Le mardi 25 juin 2013 21:15:11 Uwe Schindler a écrit :
This is a slightly different
workflow, but is proven to work since years now.
great workflow
here, at maven project, we use release plugin: this is a slightly different
workflow, but is proven to work since years now.
Regards,
Hervé
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:
Could someone with JIRA karma please move this ticket to the Mojo's RPM
Maven Plugin project? I don't have those privs it seems.
/Anders
On Tue, Jun 25, 2013 at 6:33 PM, Andres Danter (JIRA) j...@apache.orgwrote:
Andres Danter created MPOM-45:
-
That'll be hard. This issue is created on the JIRA of Apache, whereas the
RPM is located on the one of Codehaus.
Robert
Op Tue, 25 Jun 2013 22:23:07 +0200 schreef Anders Hammar
and...@hammar.net:
Could someone with JIRA karma please move this ticket to the Mojo's RPM
Maven Plugin
+1
Op Tue, 25 Jun 2013 08:46:21 +0200 schreef Ralph Goers
ralph.go...@dslextreme.com:
KEYS file - http://svn.apache.org/repos/asf/maven/project/KEYS
svn tag -
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.9.1
+1 on the release however it is odd that the
Especially in other environments where it's used properly, by its own
principals! :-p
On Tue, Jun 25, 2013 at 9:43 PM, Hervé BOUTEMY herve.bout...@free.frwrote:
Le mardi 25 juin 2013 21:15:11 Uwe Schindler a écrit :
This is a slightly different
workflow, but is proven to work since years
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
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,
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
2013/6/26 sebb seb...@gmail.com:
It would be a lot better to use RC1 RC2 etc initially, and copy the
successful tag to the GA tag.
this mean modifying manually the pom to change version (from 1.0-RC1
to 1.0) before copying teh RC tag, changing the scm information etc...
Rebuild jars ? because
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
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
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
-1
Except then the poms will point to the wrong place.
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
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
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
For historical reason this has changed etc..
Use org.apache.maven.plugins (same as groupId)
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
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
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
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
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
You havn't done this much have you?
mvn release:perform can be rerun and if you clean it the checkout will
always be into a clean location ./target/checkout/ by default.
On Wed, Jun 26, 2013 at 10:11 AM, sebb seb...@gmail.com wrote:
On 26 June 2013 00:34, Chris Graham chrisgw...@gmail.com
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
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
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
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?
2013/6/26 sebb seb...@gmail.com:
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.
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?
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.
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
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
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
funny discussion which come back around every 3years
:-)
2013/6/26 sebb seb...@gmail.com:
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
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
*
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
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
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
+1
easy to use, very powerful, and produces artifacts consistent with scm
and for those who didn't read the doc: prepare [1] and perform [2]
[1]
http://maven.apache.org/maven-release/maven-release-plugin/examples/prepare-release.html
[2]
59 matches
Mail list logo
