Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
Hervé BOUTEMY wrote: the rationale behind not going directly to 3.0 was that site plugin is hard to test, particularly now that it is both compatible with Maven 2 and Maven 3, which is something really new and probably tested by only a few of us I don't quite agree with this rationale. Ease of testing is not a criterion for version naming IMO. The main criterion is how many *known* bugs and missing features there are left. So what are the open issues that we are aware about? If there are none or only a few, then let's call it final. If the people who are working on the release feel that the stuff is stable (which I do) then why not release it as such? sure, 3.0-beta-4 should at least be 3.0-RC-1, but perhaps not 3.0 immediately: I'm pretty sure we'll find some important problems when a lot of people try it seriously The most efficient way to get people to test something, is to release it! :) There are real important factors to test, which makes a lot of combinations: - Maven version: 2.2.x, 3.x - OS - phases: site, site-deploy, site:stage-deploy (run? jar?) should all be covered by our ITs: https://builds.apache.org/job/maven-site-plugin-2.x/ https://builds.apache.org/job/maven-site-plugin-3.x/ https://builds.apache.org/job/maven-site-plugin-3.x-m2/ I am aware that there are some important differences though, (some ITs are skipped with m3, or executed with different parameters), which would be important to review and document I guess. - deploy protocol: scp, webdav not really a site-plugin concern, rather wagon - report plugins used: I don't know how to describe without being a mess... We (devs) cannot test everything, even the more important it is to get user feedback. But at least, with maven-site-plugin 2.3 being out and almost equivalent (particularly when it comes to Doxia and Doxia Site Tools), we have a clear line to check if a problem with 3.0 is a regression from 2.3 or not so this would rather be an argument in favour of 3.0...? Then I'd better be for 3.0-RC-1 for the moment. I will support whatever the release manager decides, but I would prefer 3.0-final with a number of bug fix releases following, rather than an open interval of [RC-1, RC-2,...). More people will test the final release and there will be more pressure on us to push for bug-fix versions (which is good! :) ). -Lukas Such a discussion happened a lot of time in the past: 3.0 and 3.0-RC-1 are good choices, but not 3.0-beta-4 The release manager can choose and I'll be with him. But IMHO we need to ask for people to tell what conditions they tested. Regards, Hervé Le mercredi 6 juillet 2011, Olivier Lamy a écrit : No objections from me. beta cycle has started long time ago. 2011/7/6 Lukas Theusslltheu...@apache.org: Any objections to making this 3.0-final? AFAICT the plugin is functionally (almost) equivalent to the 2.x trunk version (only exception is MSITE-484?), so why keep the beta? -Lukas Dennis Lundberg wrote: Hi What's the status on this? I know Hervé worked on extracting a shared component (maven-reporting-exec) for the Maven 3 specific parts of the plugin. Did you finish with that? I would like to push for a release of Site Plugin 3 shortly. The only issue left according to JIRA is this one: http://jira.codehaus.org/browse/MSITE-560 There are a lot stuff fixed already, and we need to get this out so that Maven 3 users can benefit from them. Do we want/need to add anything more before the release? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
Lukas Theussl wrote: Hervé BOUTEMY wrote: the rationale behind not going directly to 3.0 was that site plugin is hard to test, particularly now that it is both compatible with Maven 2 and Maven 3, which is something really new and probably tested by only a few of us I don't quite agree with this rationale. Ease of testing is not a criterion for version naming IMO. The main criterion is how many *known* bugs and missing features there are left. So what are the open issues that we are aware about? If there are none or only a few, then let's call it final. If the people who are working on the release feel that the stuff is stable (which I do) then why not release it as such? sure, 3.0-beta-4 should at least be 3.0-RC-1, but perhaps not 3.0 immediately: I'm pretty sure we'll find some important problems when a lot of people try it seriously The most efficient way to get people to test something, is to release it! :) There are real important factors to test, which makes a lot of combinations: - Maven version: 2.2.x, 3.x - OS - phases: site, site-deploy, site:stage-deploy (run? jar?) should all be covered by our ITs: https://builds.apache.org/job/maven-site-plugin-2.x/ https://builds.apache.org/job/maven-site-plugin-3.x/ https://builds.apache.org/job/maven-site-plugin-3.x-m2/ I am aware that there are some important differences though, (some ITs are skipped with m3, or executed with different parameters), which would be important to review and document I guess. - deploy protocol: scp, webdav not really a site-plugin concern, rather wagon - report plugins used: I don't know how to describe without being a mess... We (devs) cannot test everything, even the more important it is to get user feedback. But at least, with maven-site-plugin 2.3 being out and almost equivalent (particularly when it comes to Doxia and Doxia Site Tools), we have a clear line to check if a problem with 3.0 is a regression from 2.3 or not so this would rather be an argument in favour of 3.0...? Then I'd better be for 3.0-RC-1 for the moment. I will support whatever the release manager decides, but I would prefer 3.0-final with a number of bug fix releases following, rather than an open interval of [RC-1, RC-2,...). More people will test the final release and there will be more pressure on us to push for bug-fix versions (which is good! :) ). From user's perspective: +1 Especially since this is the first version that can be used by M3 and M2. - Jörg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Shared Component Maven Reporting Exec 1.0
+1 -Lukas Olivier Lamy wrote: Hi, Here a vote to release the first version of maven-reporting-exec component This component contains necessary code to run site plugin with maven 3. So currently no jira issues as it's a simply an extraction of code from maven site plugin for maven 3 branch [1] Staging repo : https://repository.apache.org/content/repositories/maven-015/ Site : http://maven.apache.org/shared/maven-reporting-exec/ (wait sync as currently it's an old 1.0-SNAPSHOT deployed) You can test it with the site plugin 3.x branch [1] Vote open for 72H. [ ] +1 [ ] +0 [ ] -1 Here my +1. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Transitive release notes from Jira ?
I see we all do this great job of tracking issues/bugs in Jira, but at some point we just move one of the dependent libraries from 2.1 to 2.2 or from 2.1 to 3.0. I somehow find that I need to create linked issues for some important changes, such as creating a MJAR issue called updated plexus-archiver to version 2.0 to get java 1.7 file attribute support; but I also feel that I am repeating myself in oh so many ways when I do this. Is there any way to get the proper transitive diff between version X and Y in jira that can be used in creating release notes ? (And not just 1 level, there's sometimes important fixes going on deep in the dependency hierarchy and I find I forget things I've done myself ;) Kristian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
We've been running the beta for (I don't know how many) months, and works better than it ever has. I agree with Lukas; release it. On Thu, Jul 7, 2011 at 2:26 AM, Lukas Theussl ltheu...@apache.org wrote: Hervé BOUTEMY wrote: the rationale behind not going directly to 3.0 was that site plugin is hard to test, particularly now that it is both compatible with Maven 2 and Maven 3, which is something really new and probably tested by only a few of us I don't quite agree with this rationale. Ease of testing is not a criterion for version naming IMO. The main criterion is how many *known* bugs and missing features there are left. So what are the open issues that we are aware about? If there are none or only a few, then let's call it final. If the people who are working on the release feel that the stuff is stable (which I do) then why not release it as such? sure, 3.0-beta-4 should at least be 3.0-RC-1, but perhaps not 3.0 immediately: I'm pretty sure we'll find some important problems when a lot of people try it seriously The most efficient way to get people to test something, is to release it! :) There are real important factors to test, which makes a lot of combinations: - Maven version: 2.2.x, 3.x - OS - phases: site, site-deploy, site:stage-deploy (run? jar?) should all be covered by our ITs: https://builds.apache.org/job/maven-site-plugin-2.x/ https://builds.apache.org/job/maven-site-plugin-3.x/ https://builds.apache.org/job/maven-site-plugin-3.x-m2/ I am aware that there are some important differences though, (some ITs are skipped with m3, or executed with different parameters), which would be important to review and document I guess. - deploy protocol: scp, webdav not really a site-plugin concern, rather wagon - report plugins used: I don't know how to describe without being a mess... We (devs) cannot test everything, even the more important it is to get user feedback. But at least, with maven-site-plugin 2.3 being out and almost equivalent (particularly when it comes to Doxia and Doxia Site Tools), we have a clear line to check if a problem with 3.0 is a regression from 2.3 or not so this would rather be an argument in favour of 3.0...? Then I'd better be for 3.0-RC-1 for the moment. I will support whatever the release manager decides, but I would prefer 3.0-final with a number of bug fix releases following, rather than an open interval of [RC-1, RC-2,...). More people will test the final release and there will be more pressure on us to push for bug-fix versions (which is good! :) ). -Lukas Such a discussion happened a lot of time in the past: 3.0 and 3.0-RC-1 are good choices, but not 3.0-beta-4 The release manager can choose and I'll be with him. But IMHO we need to ask for people to tell what conditions they tested. Regards, Hervé Le mercredi 6 juillet 2011, Olivier Lamy a écrit : No objections from me. beta cycle has started long time ago. 2011/7/6 Lukas Theusslltheu...@apache.org: Any objections to making this 3.0-final? AFAICT the plugin is functionally (almost) equivalent to the 2.x trunk version (only exception is MSITE-484?), so why keep the beta? -Lukas Dennis Lundberg wrote: Hi What's the status on this? I know Hervé worked on extracting a shared component (maven-reporting-exec) for the Maven 3 specific parts of the plugin. Did you finish with that? I would like to push for a release of Site Plugin 3 shortly. The only issue left according to JIRA is this one: http://jira.codehaus.org/browse/MSITE-560 There are a lot stuff fixed already, and we need to get this out so that Maven 3 users can benefit from them. Do we want/need to add anything more before the release? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Semi-serious blog post
http://dssheep.blogspot.com/2011/07/maven-seder.html - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: svn commit: r1143543 - /maven/pom/trunk/maven/src/site/site.xml
thnx :) It's a small though important adjustment. I noticed some wandering newbies looking for M3 docs. Right now it looks too often it's just M2.We might need to add an entry on the guides-page[1] about upgrading from M2 to M3, just to be complete. Let me do a quick scan, see if I can update some of those labels. -Robert [1] http://maven.apache.org/guides/index.html From: herve.bout...@free.fr To: dev@maven.apache.org Subject: Re: svn commit: r1143543 - /maven/pom/trunk/maven/src/site/site.xml Date: Thu, 7 Jul 2011 01:45:27 +0200 Welcome Robert very nice catch for a first commit :) Le mercredi 6 juillet 2011, rfscho...@apache.org a écrit : Author: rfscholte Date: Wed Jul 6 20:18:03 2011 New Revision: 1143543 URL: http://svn.apache.org/viewvc?rev=1143543view=rev Log: Change link text in menu to 'Maven 2 3' when referring to http://maven.apache.org Modified: maven/pom/trunk/maven/src/site/site.xml Modified: maven/pom/trunk/maven/src/site/site.xml URL: http://svn.apache.org/viewvc/maven/pom/trunk/maven/src/site/site.xml?rev=1 143543r1=1143542r2=1143543view=diff == --- maven/pom/trunk/maven/src/site/site.xml (original) +++ maven/pom/trunk/maven/src/site/site.xml Wed Jul 6 20:18:03 2011 @@ -67,7 +67,7 @@ under the License. item name=Doxia href=http://maven.apache.org/doxia/index.html; / item name=JXR href=http://maven.apache.org/jxr/index.html; / item name=Maven 1.x href=http://maven.apache.org/maven-1.x/index.html; / - item name=Maven 2 href=http://maven.apache.org/index.html; / + item name=Maven 2 amp; 3 href=http://maven.apache.org/index.html; / item name=Plugins href=http://maven.apache.org/plugins/index.html; / item name=SCM href=http://maven.apache.org/scm/index.html; / item name=Shared Components href=http://maven.apache.org/shared/index.html; / - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
I forgot we had this great Jenkins instance with lots of OSes and configuration combinations, and improved ITs to cover a lot of cases (more than +50% over 3.0-beta-3) Then I'm now confident that we can release a good quality even without a lot of users having done tests themselves. +1 for 3.0 final: it won't be over-estimated! Regards, Hervé Le jeudi 7 juillet 2011, Lukas Theussl a écrit : Hervé BOUTEMY wrote: the rationale behind not going directly to 3.0 was that site plugin is hard to test, particularly now that it is both compatible with Maven 2 and Maven 3, which is something really new and probably tested by only a few of us I don't quite agree with this rationale. Ease of testing is not a criterion for version naming IMO. The main criterion is how many *known* bugs and missing features there are left. So what are the open issues that we are aware about? If there are none or only a few, then let's call it final. If the people who are working on the release feel that the stuff is stable (which I do) then why not release it as such? sure, 3.0-beta-4 should at least be 3.0-RC-1, but perhaps not 3.0 immediately: I'm pretty sure we'll find some important problems when a lot of people try it seriously The most efficient way to get people to test something, is to release it! :) There are real important factors to test, which makes a lot of combinations: - Maven version: 2.2.x, 3.x - OS - phases: site, site-deploy, site:stage-deploy (run? jar?) should all be covered by our ITs: https://builds.apache.org/job/maven-site-plugin-2.x/ https://builds.apache.org/job/maven-site-plugin-3.x/ https://builds.apache.org/job/maven-site-plugin-3.x-m2/ I am aware that there are some important differences though, (some ITs are skipped with m3, or executed with different parameters), which would be important to review and document I guess. - deploy protocol: scp, webdav not really a site-plugin concern, rather wagon - report plugins used: I don't know how to describe without being a mess... We (devs) cannot test everything, even the more important it is to get user feedback. But at least, with maven-site-plugin 2.3 being out and almost equivalent (particularly when it comes to Doxia and Doxia Site Tools), we have a clear line to check if a problem with 3.0 is a regression from 2.3 or not so this would rather be an argument in favour of 3.0...? Then I'd better be for 3.0-RC-1 for the moment. I will support whatever the release manager decides, but I would prefer 3.0-final with a number of bug fix releases following, rather than an open interval of [RC-1, RC-2,...). More people will test the final release and there will be more pressure on us to push for bug-fix versions (which is good! :) ). -Lukas Such a discussion happened a lot of time in the past: 3.0 and 3.0-RC-1 are good choices, but not 3.0-beta-4 The release manager can choose and I'll be with him. But IMHO we need to ask for people to tell what conditions they tested. Regards, Hervé Le mercredi 6 juillet 2011, Olivier Lamy a écrit : No objections from me. beta cycle has started long time ago. 2011/7/6 Lukas Theusslltheu...@apache.org: Any objections to making this 3.0-final? AFAICT the plugin is functionally (almost) equivalent to the 2.x trunk version (only exception is MSITE-484?), so why keep the beta? -Lukas Dennis Lundberg wrote: Hi What's the status on this? I know Hervé worked on extracting a shared component (maven-reporting-exec) for the Maven 3 specific parts of the plugin. Did you finish with that? I would like to push for a release of Site Plugin 3 shortly. The only issue left according to JIRA is this one: http://jira.codehaus.org/browse/MSITE-560 There are a lot stuff fixed already, and we need to get this out so that Maven 3 users can benefit from them. Do we want/need to add anything more before the release? - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Shared Component Maven Reporting Exec 1.0
+1 from me On 2011-07-05 16:00, Olivier Lamy wrote: Hi, Here a vote to release the first version of maven-reporting-exec component This component contains necessary code to run site plugin with maven 3. So currently no jira issues as it's a simply an extraction of code from maven site plugin for maven 3 branch [1] Staging repo : https://repository.apache.org/content/repositories/maven-015/ Site : http://maven.apache.org/shared/maven-reporting-exec/ (wait sync as currently it's an old 1.0-SNAPSHOT deployed) You can test it with the site plugin 3.x branch [1] Vote open for 72H. [ ] +1 [ ] +0 [ ] -1 Here my +1. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Jenkins failures
Hi I've just deployed the latest SNAPSHOTs of the ASF and Maven parent POMs. That should hopefully make Jenkins shut up. -- Dennis Lundberg - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
[jira] Subscription: Design Best Practices
Issue Subscription
Filter: Design Best Practices (24 issues)
Subscriber: mavendevlist
Key Summary
MNG-2184Possible problem with @aggregator and forked lifecycles
https://jira.codehaus.org/browse/MNG-2184
MNG-612 implement conflict resolution techniques
https://jira.codehaus.org/browse/MNG-612
MNG-1950Ability to introduce new lifecycles phases
https://jira.codehaus.org/browse/MNG-1950
MNG-2381improved control over the repositories in the POM
https://jira.codehaus.org/browse/MNG-2381
MNG-1563how to write integration tests
https://jira.codehaus.org/browse/MNG-1563
MNG-2125[doc] when and how to define plugins in a pom
https://jira.codehaus.org/browse/MNG-2125
MNG-139 server definitions should be reusable - review use of repository IDs
https://jira.codehaus.org/browse/MNG-139
MNG-474 performance improvement for forked lifecycles
https://jira.codehaus.org/browse/MNG-474
MNG-1381best practices: testing strategies
https://jira.codehaus.org/browse/MNG-1381
MNG-4656Declarative plugins similar to jsp tags or jsf composites
https://jira.codehaus.org/browse/MNG-4656
MNG-4713${basedir} variable makes portable builds overly difficult
https://jira.codehaus.org/browse/MNG-4713
MNG-1569Make build process info read-only to mojos, and provide mechanism
for explicit out-params for mojos to declare
https://jira.codehaus.org/browse/MNG-1569
MNG-416 best practices: multiple profile deployments
https://jira.codehaus.org/browse/MNG-416
MNG-367 best practices: multi-user installation
https://jira.codehaus.org/browse/MNG-367
MNG-125 guarded mojo execution
https://jira.codehaus.org/browse/MNG-125
MNG-41 best practices: site management
https://jira.codehaus.org/browse/MNG-41
MNG-1441Starting thinking about a proper distributed repository mechanism a
la CPAN
https://jira.codehaus.org/browse/MNG-1441
MNG-868 Use uniform format for properties and other tags
https://jira.codehaus.org/browse/MNG-868
MNG-1425best practices: the location of configuration files vs resources
https://jira.codehaus.org/browse/MNG-1425
MNG-1463best practices: plugin inheritance for a multi project build
https://jira.codehaus.org/browse/MNG-1463
MNG-657 possible chicken and egg problem with extensions
https://jira.codehaus.org/browse/MNG-657
MNG-1867deprecate system scope, analyse other use cases
https://jira.codehaus.org/browse/MNG-1867
MNG-1423best practices: setting up multi-module build
https://jira.codehaus.org/browse/MNG-1423
MNG-1468best practices: version management in multi project builds
https://jira.codehaus.org/browse/MNG-1468
You may edit this subscription at:
https://jira.codehaus.org/secure/FilterSubscription!default.jspa?subId=10341filterId=11471
-
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
Re: Is Maven Site Plugin 3.0-beta-4 ready for release?
On Thu, 7 Jul 2011 21:22:43 +0200 Hervé BOUTEMY herve.bout...@free.fr wrote: I forgot we had this great Jenkins instance with lots of OSes and configuration combinations, and improved ITs to cover a lot of cases (more than +50% over 3.0-beta-3) Then I'm now confident that we can release a good quality even without a lot of users having done tests themselves. +1 for 3.0 final: it won't be over-estimated! Something was detected as a regression in last stable version of version 2.3 of the site plugin Lukas added a IT for this case [1] and has also a ticket [2]. If this is not ok, this is for my part a none reason to a final release ? I don't know the difficulty to fix this problem... [1] http://svn.apache.org/viewvc?rev=1126420view=rev [2] http://jira.codehaus.org/browse/MSITE-585 -- 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] Shared Component Maven Reporting Exec 1.0
+1 Den 7. juli 2011 kl. 12:07 skrev Lukas Theussl ltheu...@apache.org: +1 -Lukas Olivier Lamy wrote: Hi, Here a vote to release the first version of maven-reporting-exec component This component contains necessary code to run site plugin with maven 3. So currently no jira issues as it's a simply an extraction of code from maven site plugin for maven 3 branch [1] Staging repo : https://repository.apache.org/content/repositories/maven-015/ Site : http://maven.apache.org/shared/maven-reporting-exec/ (wait sync as currently it's an old 1.0-SNAPSHOT deployed) You can test it with the site plugin 3.x branch [1] Vote open for 72H. [ ] +1 [ ] +0 [ ] -1 Here my +1. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: [VOTE] Shared Component Maven Reporting Exec 1.0
On Tue, 5 Jul 2011 16:00:12 +0200 Olivier Lamy ol...@apache.org wrote: Hi, +1 Tony Here a vote to release the first version of maven-reporting-exec component This component contains necessary code to run site plugin with maven 3. So currently no jira issues as it's a simply an extraction of code from maven site plugin for maven 3 branch [1] Staging repo : https://repository.apache.org/content/repositories/maven-015/ Site : http://maven.apache.org/shared/maven-reporting-exec/ (wait sync as currently it's an old 1.0-SNAPSHOT deployed) You can test it with the site plugin 3.x branch [1] Vote open for 72H. [ ] +1 [ ] +0 [ ] -1 Here my +1. -- 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
