fixed:
http://maven.apache.org/plugins-archives/maven-javadoc-plugin-2.9.1/jira-report.html
2013/6/25 Olivier Lamy :
> 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 :
On 25 June 2013 07:46, Ralph Goers 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
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 :
> On 25 June 2013 07:46, Ralph Goers 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/
2013/6/25 sebb :
> 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 committers to
On 25 June 2013 11:49, Olivier Lamy wrote:
> 2013/6/25 sebb :
>> 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 s
2013/6/25 sebb :
> On 25 June 2013 11:49, Olivier Lamy wrote:
>> 2013/6/25 sebb :
>>> 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 depl
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 w
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
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
tha
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 wrote:
> I disagree that the revision is required. I know that the RM 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 eve
On Tue, Jun 25, 2013 at 2:19 PM, Ralph Goers 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 reru
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 pr
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
> wrote:
>
>> Again I have to disagree. The release manager will send an email clos
-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
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 b
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 wrote:
> Hi,
>
> I agree with sebb. I am not a Maven committer, but the release revision is
> very important in the Lucene Project (where
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=11530&version=19011
There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11530&status=1
Staging repo:
https://repository.apache.org/content/reposito
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) wrote:
> Andres Danter created MPOM-45:
> -
>
> Summary: RP
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
:
Could someone with JIRA karma please move this ticket to the Mojo's RPM
Maven Plugin project? I don't have tho
+1
Op Tue, 25 Jun 2013 08:46:21 +0200 schreef Ralph Goers
:
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.
R
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 wrote:
> 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 workfl
On 25 June 2013 19:19, Ralph Goers 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 r
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 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
On 25 June 2013 19:33, Hervé BOUTEMY 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 doe
2013/6/26 sebb :
> 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 if you change t
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 wrote:
> The mission of the ASF is to release software as source, and to ensure
> that the released sour
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 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 wrote:
> > Yeah - I agree with this. I rename them to rc1, rc2, etc after a failed
> relea
-1
Except then the poms will point to the wrong place.
On Wed, Jun 26, 2013 at 10:01 AM, Gary Gregory wrote:
> On Tue, Jun 25, 2013 at 7:14 PM, sebb 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 26 June 2013 01:04, Chris Graham 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 wrote:
>
>> On Tue, Jun 25, 2013 at 7:14 PM, sebb wrote:
>>
>> > It would be a lot better to use RC1 RC2 e
On 26 June 2013 00:34, Chris Graham 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 wrote:
>
>> The mission of the ASF is to relea
For historical reason this has changed etc..
Use org.apache.maven.plugins (same as groupId)
2013/6/26 sebb :
> 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
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 M
On 26 June 2013 01:13, Olivier Lamy 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 :
>> Most plugins seem to be sub-packages of org.apache.maven.plugin; just
>>
> 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
manua
On 26 June 2013 01:25, Barrie Treloar 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
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 wrote:
> On 26 June 2013 00:34, Chris Graham wrote:
> > This appears to be a variant
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 :
>> And if the "mvn deploy" fails for any reason?
>
> We get this often enough with a crappy connection
On 25 June 2013 20:15, Uwe Schindler 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
On Wed, Jun 26, 2013 at 10:36 AM, sebb 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?
Please go and run
2013/6/26 sebb :
> 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 a
On 26 June 2013 01:43, Chris Graham wrote:
> On Wed, Jun 26, 2013 at 10:36 AM, sebb 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
On 26 June 2013 01:41, Olivier Lamy 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 c
On 26 June 2013 09:47, sebb 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 fil
On 26 June 2013 02:14, Barrie Treloar wrote:
> On 26 June 2013 09:47, sebb 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
>> l
On 26 June 2013 10:19, sebb wrote:
> On 26 June 2013 01:41, Olivier Lamy 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
funny discussion which come back around every 3years
:-)
2013/6/26 sebb :
> On 26 June 2013 02:14, Barrie Treloar wrote:
>> On 26 June 2013 09:47, sebb wrote:
>>> I could not find any download links for Maven source packages.
>>>
>>> As the ASF primary purpose is to release source, and that mus
On 26 June 2013 02:18, Barrie Treloar wrote:
> On 26 June 2013 10:19, sebb wrote:
>> On 26 June 2013 01:41, Olivier Lamy wrote:
>>> correct.
>>> In case of failure during deploy:
>>> * cd target/checkout && mvn clean deploy -Papache-release
>>> or
>>> * export/checkout the tag && mvn clean deplo
On 26 June 2013 10:48, sebb 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 re
>> Then replace
>> cd target/checkout && mvn clean deploy -Papache-release
>> with
>> delete target/checkout
>> svn co 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 i
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 wrote:
> > -1
> > Except then the poms will point to the wrong place.
>
> Depends how the poms are updated.
>
> > On Wed, Jun 26,
+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]
http://maven.apache.org/maven-release/maven-release-plug
56 matches
Mail list logo
