Re: [VOTE] Apache Maven Javadoc Plugin 2.9.1 (take 2)
On Tue, 25 Jun 2013 22:52:31 +0200 Robert Scholte rfscho...@apache.org wrote: +1 tony. +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 Release Notes page is empty. 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 -- 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] Release Maven Enforcer version 1.3 (take 2)
On Tue, 25 Jun 2013 22:23:13 +0200 Robert Scholte rfscho...@apache.org wrote: +1, tony. 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 [ ] -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: 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 For
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 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. 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 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
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: Download links for source packages - where are they?
On 26 June 2013 18:44, sebb seb...@gmail.com 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: 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 name]. Thanks, Jörg - 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 name]. 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 joerg.schai...@scalaris.com: 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 name]. 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
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 kristian.rosenv...@gmail.com: 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 joerg.schai...@scalaris.com: 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 name]. 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: Download links for source packages - where are they?
On Wednesday, 26 June 2013, Barrie Treloar wrote: On 26 June 2013 18:44, sebb seb...@gmail.com javascript:; 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 javascript:; For additional commands, e-mail: dev-h...@maven.apache.org javascript:; -- Sent from my phone
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 joerg.schai...@scalaris.com 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 name]. 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: 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 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. 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
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
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. 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
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.
