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 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 : >> 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" wrote: >> >>> On 26 June 2013 10:56, Chris Graham wrote: >>> > On Wed, Jun 26, 2013 at 7:06 PM, sebb 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 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 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 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 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 >>> >> >> >> >>> >> >> >> > 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.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. >>> >> >> >> > >> >>> >> >> >> > >> 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 >>> >> >> >> > >>
Re: Release process updates
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 : > 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" wrote: > >> On 26 June 2013 10:56, Chris Graham wrote: >> > On Wed, Jun 26, 2013 at 7:06 PM, sebb 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 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 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 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 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 >> >> >> >> >> >> >> >> > 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.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. >> >> >> >> > >> >> >> >> >> > >> 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, >> >> >> >> > >
Re: svn commit: r1497151 - /maven/site/trunk/content/xdoc/download.xml.vm
On 26 June 2013 23:54, 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=1497151&r1=1497150&r2=1497151&view=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. > > All previous releases of Maven can be found in the href="http://archive.apache.org/dist/maven/binaries/";>archives. > > + > +All sources (plugins, shared librairies, scm, indexer etc..) can > be downloaded from href="http://www.us.apache.org/dist/maven/";>http://www.us.apache.org/dist/maven/ 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. > + > > > > > - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Release process updates
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" wrote: > On 26 June 2013 10:56, Chris Graham wrote: > > On Wed, Jun 26, 2013 at 7:06 PM, sebb 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 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 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 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 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 > >> >> >> > >> >> >> > 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.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. > >> >> >> > >> > >> >> >> > >> 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 > >> >> >> > > >> >> >> > >>> t
Re: Maven 3.1.0-beta-1
I will resurrect the performance framework that Igor build long ago. I should be running it when major changes are made. I'll report back later this week. I need to find an old, crappy machine to run them on to gauge the difference accurately. On Jun 26, 2013, at 8:23 AM, Jörg Schaible wrote: > Hi Jason, > > Jason van Zyl wrote: > >> Doesn't see to be a whole lot of activity around the 3.1.0-alpha-1 so I >> plan to cut the 3.1.0-beta-1 this weekend if there are no objections. > > Apart from the reported bogus build with snapshots (MNG-5207) it seems M31 > has a major problem with PermGen space leakage. > > We have currently a build that contains 337 projects. With M221 I can build > all of it in one run in ~11 minutes. > > With M305 the build runs faster, but I have to continue it two times with "- > rf" option, because it runs out of PermGen space. > > With M31a the leakage is really worse. The build stops because of PermGen > space 4 times, where I have to continue manually again. > > All plugins are locked down, so it has to be related with Maven core. > MAVEN_OPTS is "-Xmx1g -XX:MaxPermSize=192m" and I am running "mvn clean > install [-rf ]". > > Thanks, > Jörg > > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > Thanks, Jason -- Jason van Zyl Founder & CTO, Sonatype Founder, Apache Maven http://twitter.com/jvanzyl -
Re: Download links for source packages - where are they?
On Wednesday, 26 June 2013, Barrie Treloar wrote: > On 26 June 2013 18:44, sebb > wrote: > > 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. > > We provide all that for Maven core - the bit the users care about and run. > > Plugins are download by Maven. > Few, if any, user is going to download a source distribution of a > plugin and built it themselves. > If they are going to do that, then they are likely to want to work on > Jira issues or provide a patch and it makes much more sense to work > with source control. > And we have prominent links to the source control repositories, > including the tags. I do not think it would be a major harm to add a reporting plugin to generate the dist download link for source bundles... As it can only add... I agree that there is no *requirement* for us to provide the download link... But there are things we can improve. Until recently, it was not clear to us that the source bundles had to be copied into the dist directory... Someone at infra wrote an audit script and we copied all the missing bundles over for plugins (they were on repository.apache.org so it is not that we hadn't generated them) I think we should turn on rat for all plugins, not just core... I will look into this next week if nobody else has... Most likely I will turn on rat without strong enforcement just yet, and then turn on zero tollerance in a month or so to give people the chance to fix rat issues and get out any emergency releases that might be required (eg if there is a CVE requiring a plugin release, you don't want that blocked while we review the integration test data that may or may not require an ASF license header for the test to be valid, and I'd rather have a valid set of exclusions rather than a "lets just get the build passing to make this release" approach which can get forgotten to unwind after) > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Sent from my phone
Re: Maven 3.1.0-beta-1
Oops. It appears the standard heap dump toosl don't really dump
permgen, so that's not going to get us anywhere.
I usually do this in jprofiler, maybe someone else has a suggestion :)
Kristian
2013/6/26 Kristian Rosenvold :
> Funny in a sort of ironic way, permgen is noticeably better in 3.1 for
> my usecases :)
>
> The simplest way to get (my) attention to this issue is to create 2
> heap dumps of your maven process, one after "some time" and the other
> just before it runs out of permgen.
>
> ("some time" is supposed to be well into the execution so I can avoid
> tracking all the *correct* permgen usage that happens at the start of
> a maven build as it loads the plugins)
>
> You can send them to me via something like dropbox or other means that handles
> large files.
>
> Use jvisualvm or one of the other tools to get the heap dumps.
>
> Kristian
>
>
> 2013/6/26 Jörg Schaible :
>> Hi Jason,
>>
>> Jason van Zyl wrote:
>>
>>> Doesn't see to be a whole lot of activity around the 3.1.0-alpha-1 so I
>>> plan to cut the 3.1.0-beta-1 this weekend if there are no objections.
>>
>> Apart from the reported bogus build with snapshots (MNG-5207) it seems M31
>> has a major problem with PermGen space leakage.
>>
>> We have currently a build that contains 337 projects. With M221 I can build
>> all of it in one run in ~11 minutes.
>>
>> With M305 the build runs faster, but I have to continue it two times with "-
>> rf" option, because it runs out of PermGen space.
>>
>> With M31a the leakage is really worse. The build stops because of PermGen
>> space 4 times, where I have to continue manually again.
>>
>> All plugins are locked down, so it has to be related with Maven core.
>> MAVEN_OPTS is "-Xmx1g -XX:MaxPermSize=192m" and I am running "mvn clean
>> install [-rf ]".
>>
>> Thanks,
>> Jörg
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
>> For additional commands, e-mail: dev-h...@maven.apache.org
>>
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.1.0-beta-1
Funny in a sort of ironic way, permgen is noticeably better in 3.1 for
my usecases :)
The simplest way to get (my) attention to this issue is to create 2
heap dumps of your maven process, one after "some time" and the other
just before it runs out of permgen.
("some time" is supposed to be well into the execution so I can avoid
tracking all the *correct* permgen usage that happens at the start of
a maven build as it loads the plugins)
You can send them to me via something like dropbox or other means that handles
large files.
Use jvisualvm or one of the other tools to get the heap dumps.
Kristian
2013/6/26 Jörg Schaible :
> Hi Jason,
>
> Jason van Zyl wrote:
>
>> Doesn't see to be a whole lot of activity around the 3.1.0-alpha-1 so I
>> plan to cut the 3.1.0-beta-1 this weekend if there are no objections.
>
> Apart from the reported bogus build with snapshots (MNG-5207) it seems M31
> has a major problem with PermGen space leakage.
>
> We have currently a build that contains 337 projects. With M221 I can build
> all of it in one run in ~11 minutes.
>
> With M305 the build runs faster, but I have to continue it two times with "-
> rf" option, because it runs out of PermGen space.
>
> With M31a the leakage is really worse. The build stops because of PermGen
> space 4 times, where I have to continue manually again.
>
> All plugins are locked down, so it has to be related with Maven core.
> MAVEN_OPTS is "-Xmx1g -XX:MaxPermSize=192m" and I am running "mvn clean
> install [-rf ]".
>
> Thanks,
> Jörg
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
> For additional commands, e-mail: dev-h...@maven.apache.org
>
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.1.0-beta-1
Are you able to provide standalone example project that demonstrates the problem? -- Regards, Igor On 2013-06-26 4:23 PM, Jörg Schaible wrote: Hi Jason, Jason van Zyl wrote: Doesn't see to be a whole lot of activity around the 3.1.0-alpha-1 so I plan to cut the 3.1.0-beta-1 this weekend if there are no objections. Apart from the reported bogus build with snapshots (MNG-5207) it seems M31 has a major problem with PermGen space leakage. We have currently a build that contains 337 projects. With M221 I can build all of it in one run in ~11 minutes. With M305 the build runs faster, but I have to continue it two times with "- rf" option, because it runs out of PermGen space. With M31a the leakage is really worse. The build stops because of PermGen space 4 times, where I have to continue manually again. All plugins are locked down, so it has to be related with Maven core. MAVEN_OPTS is "-Xmx1g -XX:MaxPermSize=192m" and I am running "mvn clean install [-rf ]". Thanks, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Maven 3.1.0-beta-1
Hi Jason, Jason van Zyl wrote: > Doesn't see to be a whole lot of activity around the 3.1.0-alpha-1 so I > plan to cut the 3.1.0-beta-1 this weekend if there are no objections. Apart from the reported bogus build with snapshots (MNG-5207) it seems M31 has a major problem with PermGen space leakage. We have currently a build that contains 337 projects. With M221 I can build all of it in one run in ~11 minutes. With M305 the build runs faster, but I have to continue it two times with "- rf" option, because it runs out of PermGen space. With M31a the leakage is really worse. The build stops because of PermGen space 4 times, where I have to continue manually again. All plugins are locked down, so it has to be related with Maven core. MAVEN_OPTS is "-Xmx1g -XX:MaxPermSize=192m" and I am running "mvn clean install [-rf ]". Thanks, Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Download links for source packages - where are they?
On 26 June 2013 18:44, sebb wrote: > 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. We provide all that for Maven core - the bit the users care about and run. Plugins are download by Maven. Few, if any, user is going to download a source distribution of a plugin and built it themselves. If they are going to do that, then they are likely to want to work on Jira issues or provide a patch and it makes much more sense to work with source control. And we have prominent links to the source control repositories, including the tags. - 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 wrote: > On Wed, Jun 26, 2013 at 7:06 PM, sebb 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 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 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 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 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 >> >> >> >> >> >> > 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.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. >> >> >> > >> >> >> >> > >> 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
Re: Release process updates
On 26 June 2013 02:59, Barrie Treloar wrote: >>> 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 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 Wed, Jun 26, 2013 at 7:06 PM, sebb 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. > 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. > 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 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 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 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 > >> >> > >> >> > 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.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. > >> >> > >> > >> >> > >> 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
Re: Download links for source packages - where are they?
On 26 June 2013 02:48, Barrie Treloar wrote: > 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 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
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 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 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 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 >> >> >> >> > 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.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. >> >> > >> >> >> > >> 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 cr
Re: [VOTE] Release Maven Enforcer version 1.3 (take 2)
On Tue, 25 Jun 2013 22:23:13 +0200 "Robert Scholte" wrote: +1, tony. > Hi, > > We solved 15 issues: > http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11530&version=19011 > > There are still a couple of issues left in JIRA: > http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11530&status=1 > > Staging repo: > https://repository.apache.org/content/repositories/maven-070/ > https://repository.apache.org/content/repositories/maven-070/org/apache/maven/enforcer/enforcer/1.3/enforcer-1.3-source-release.zip > > Staging site: > http://maven.apache.org/enforcer-archives/enforcer-LATEST/ > > Guide to testing staged releases: > http://maven.apache.org/guides/development/guide-testing-releases.html > > Vote open for 72 hours. > > [ ] +1 > [ ] +0 > [ ] -1 > > - > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - 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 Tue, 25 Jun 2013 22:52:31 +0200 "Robert Scholte" wrote: +1 tony. > +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. > > > > Ralph > > > > On Jun 24, 2013, at 7:15 PM, sebb wrote: > > > >> On 25 June 2013 02:48, Olivier Lamy 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=18843&styleName=Text&projectId=11138&Create=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 > -- Tony Chemit tél: +33 (0) 2 40 50 29 28 email: che...@codelutin.com http://www.codelutin.com - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
