Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
Hi Nestor
The version.override feature is not a plugin it's an extension to the maven
base installation. So,
http://search.maven.org/#artifactdetails|ch.rotscher.maven.core|maven-core-extensions|0.2.0|jarhas
to be installed to your
*MAVEN_HOME/lib/ext*.
The extension is then activated with *-Dversion.override* on the command
line. It changes the version on the fly but only for the current build and
without changing the pom file. There are several strategies on how the
version is generated.
Beware, that the groupId of the root pom is taken into account whether the
version of a module or dependency should be changed to ${version.override}.
E.g. groupId is *com.foo.bar* then all modules/dependencies with
com.foo.bar and com.foo.bar.* are included. In other words the extension
assumes all modules/dependencies with the same base groupId to be in the
same reactor.
Cheers,
Rotsch
Re: [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave (was Re: svn commit: r1506778 - /maven/site/trunk/content/markdown/project-roles.md)
About growing the PMC, I suppose we're looping here ;-). IIUC, again, I think the point is precisely to define those values/rules to be able to induct more serenely new PMC members while asking them to adhere to those definitions. I think that, so far, this idea has not found much favour with the broader community. I am not sure how you get someone to promise not to undertake enhancements that result in too much code or add too much functionality. The actual wording of the proposed litmus test only indirectly addressed this and seemed to be an attempt to codify a personality conflict with rules that would hurt the long-term viability of the project by replacing innovation with the group-think of an inner clique. It also seemed to go against the principle of open source. At least, that was the way it appeared to me as a community member outside the PMC. At the moment, the words themselves are meaningless (as they are still up for debate - and why this thread was created, so that they could be crafted by the community). Once there is some consensus they will be used in the future. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
On 2 August 2013 06:51, Stephen Connolly
stephen.alan.conno...@gmail.com wrote:
On Friday, 2 August 2013, Stephen Colebourne wrote:
I'm trying to argue that that your perception of it being bad practice
is out of place. It is very common for teams to want to have a tree of
modules that are all versioned together with a single version number.
Then they all should have a common parent and use parent version
inheritance.
They do. But its never that simple. Some of the child modules are
public and some are private (of the same public parent). Since the
names of the private ones cannot be exposed in the public area, we
have a separate private aggregator to pull the private and public into
the same reactor where everything works fine.
I have tested the changes, and they replicate the set-aggregated goal
I wrote. I still think a separate goal is clearer to document and use,
but its your plugin. I think you're going to need quite a lot of
documentation to describe what the plugin is supposed to do. For
example, for my use case, only the artifactId needs to be wildcarded.
There is one area where the plugin does not update (nor did set-aggregated):
dependency
groupIdcom.opengamma.platform/groupId
artifactIdog-integration/artifactId
version${og.version}/version
/dependency
Because it is a property, it is not updated. I think this is a separate issue.
Thanks for working on this. Once released it will work effectively
enough for us, with just the one manual ${og.version} property change.
Stephen
-
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org
[DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
I have updated the project-roles with my thoughts resulting from the healthy debate on the list and some debates elsewhere. If anyone wants to look at the resulting Work In Progress document as a whole: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup Thoughts? -Stephen -- Forwarded message -- From: steph...@apache.org Date: 2 August 2013 10:52 Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ project-roles.md To: comm...@maven.apache.org Author: stephenc Date: Fri Aug 2 09:52:11 2013 New Revision: 1509594 URL: http://svn.apache.org/r1509594 Log: After a lengthy discussion on the users@maven list and some side discussions on members@apache, I think the following changes are more in line with what we should be seeking as responsibilities of the PMC. * Forks are not bad... letting changes stack up in the fork is bad but more from a 'it will be hard to review' point of view... similarly using a fork to get external contributions complicates the tracablity * We are not obligated to promote other ASF projects... but there should be a symmetry in how that lack of obligation plays out * I identified some more responsibilities of the PMC (if I have missed any, please add) * There is a special case where the PMC Chair can wear the dictators hat... but that is only in the case of unresolvable consensus and the lack of consensus is causing damage to the project and the board is well aware of the issue and expects the chair to put on the dictators hat (with the board watching on) As always, this is a Commit Then Review community... so these changes are being committed for review. Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1509594r1=1509593r2=1509594view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Fri Aug 2 09:52:11 2013 @@ -174,11 +174,31 @@ are kept confidential. The Project Management Committee has the following responsibilities: -* Proposing active contributors for committership, -* Binding votes in project decisions, -* Voting on release artifacts, -* Ensure [Developers Conventions][5] are followed, or updated/improved if necessary, -* !-- TODO: get the rest of these -- +* Active management of those projects identified by the resolution of the Board + of Directors of the Apache Foundation; +* Ensure the project remains a healthy top-level project of the Apache Foundation + (if a PMC member wants the project to be hosted elsewhere they should resign + from the PMC stating their reason - if the PMC shrinks beyond the minimal viable + size then as a result of a desire by the bulk of the PMC to move the project + elsewhere, the Board of the Apache Foundation will take that into account + when moving the project into the Foundation's Attic) +* Prepare reports as required by the Board of the Apache Foundation and + ensure those reports are ready for presentation by the PMC Chair in a timely + manner; +* Defend the trademarks belonging to the project; +* Proposing active contributors for committership; +* Ensure that votes in the community are used as a tool to establish consensus + and not a weapon to disenfranchise or alienate a minority of the community; +* Binding votes in project decisions; +* Ensure that code committed to the project is either committed under a valid CLA + or is code that was contributed with a clear indication that the Apache License + applied (i.e. small patches submitted to the issue tracker or to the mailing list + are assumed to be submitted with the intent of being covered by the Apache + License unless the submitter clearly marks those patches as not being covered) +* Ensure that third part dependencies shipped as part of the project's releases + are covered by a compatible license. +* Voting on release artifacts; +* Ensure [Developers Conventions][5] are followed, or updated/improved if necessary; Standards for Community Commitment @@ -186,22 +206,77 @@ In the spirit of supporting the health o Management Committee members refrain from actions that subvert the functioning of the committee itself. -First, Project Management Committee members should not maintain long-running -forks of Maven code outside of the project itself. Making significant -changes to Maven code outside of the project displays a lack of -investment in the community. Additionally, attempting to re-integrate -a large number of code changes in bulk overwhelms the ability of -volunteers in the community to review (and potentially veto) the -changes. This effectively thwarts the policing function of the -PMC. - -Second, Project Management
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
@Patrick, Thanks for your reply. It has worked like a charm for three years because the team has not done continuous delivery/deployment. Now it is the time to change that and so the need is genuine: To release everything fixing version numbers on the fly with just one command that can be automated in a CI server. -- View this message in context: http://maven.40175.n5.nabble.com/continuous-releasing-versions-set-and-or-release-update-version-to-release-an-aggregator-project-tp5766275p5766589.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: continuous releasing: versions:set and/or release:update-version to release an aggregator project
@Stephen, correct. It works only for inheritance. Not for pure aggregation. -- View this message in context: http://maven.40175.n5.nabble.com/continuous-releasing-versions-set-and-or-release-update-version-to-release-an-aggregator-project-tp5766275p5766590.html Sent from the Maven - Users mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
maven assembly. package vs deploy
Hello, I'm using assembly plugin to get dir and pack it into tar.gz I'm using pretty simple config made from examples on assembly plugin site. Using my own descriptor which put all project artifacts (jars) and their deps to lib/ directory. Now if I do mvn clean package I get project jars in lib dir in format artifact-name-SNAPSHOT.jar If I do mvn clean deploy I get jars in format artifact-name-SNAPSHOT.jar + same jars in format artifact-name-$TIMESTAMP.jar where TIMESTAMP is usuall mvn deploy timestamp. So problem is that in deploy case I get same jars twice but with different names. Does anyone knows how to fix this ? Thanks in advance. -- Denis - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
I think the bulk of this is pretty good. On the fork section, specifically: As soon as changes in that fork are identified which should be brought back to the project those changes should be introduced into at least a branch hosted on the Apache Maven source control in order to facilitate the easier review by the community. The PMC should encourage by example the early committing of changes from a fork back to Apache Maven source control. This seems to want to compel code to be brought back as a responsibility, I don't think we need to spell that out. The section about the downsides to not doing so and attempting to do it later is really the core of the concerns... the extra diligence required to consume large bodies of work is bigger. That doesn't mean that code contributions are inherently bad just because they were developed elsewhere, it's just harder to pull in. On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have updated the project-roles with my thoughts resulting from the healthy debate on the list and some debates elsewhere. If anyone wants to look at the resulting Work In Progress document as a whole: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup Thoughts? -Stephen -- Forwarded message -- From: steph...@apache.org Date: 2 August 2013 10:52 Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ project-roles.md To: comm...@maven.apache.org Author: stephenc Date: Fri Aug 2 09:52:11 2013 New Revision: 1509594 URL: http://svn.apache.org/r1509594 Log: After a lengthy discussion on the users@maven list and some side discussions on members@apache, I think the following changes are more in line with what we should be seeking as responsibilities of the PMC. * Forks are not bad... letting changes stack up in the fork is bad but more from a 'it will be hard to review' point of view... similarly using a fork to get external contributions complicates the tracablity * We are not obligated to promote other ASF projects... but there should be a symmetry in how that lack of obligation plays out * I identified some more responsibilities of the PMC (if I have missed any, please add) * There is a special case where the PMC Chair can wear the dictators hat... but that is only in the case of unresolvable consensus and the lack of consensus is causing damage to the project and the board is well aware of the issue and expects the chair to put on the dictators hat (with the board watching on) As always, this is a Commit Then Review community... so these changes are being committed for review. Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1509594r1=1509593r2=1509594view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Fri Aug 2 09:52:11 2013 @@ -174,11 +174,31 @@ are kept confidential. The Project Management Committee has the following responsibilities: -* Proposing active contributors for committership, -* Binding votes in project decisions, -* Voting on release artifacts, -* Ensure [Developers Conventions][5] are followed, or updated/improved if necessary, -* !-- TODO: get the rest of these -- +* Active management of those projects identified by the resolution of the Board + of Directors of the Apache Foundation; +* Ensure the project remains a healthy top-level project of the Apache Foundation + (if a PMC member wants the project to be hosted elsewhere they should resign + from the PMC stating their reason - if the PMC shrinks beyond the minimal viable + size then as a result of a desire by the bulk of the PMC to move the project + elsewhere, the Board of the Apache Foundation will take that into account + when moving the project into the Foundation's Attic) +* Prepare reports as required by the Board of the Apache Foundation and + ensure those reports are ready for presentation by the PMC Chair in a timely + manner; +* Defend the trademarks belonging to the project; +* Proposing active contributors for committership; +* Ensure that votes in the community are used as a tool to establish consensus + and not a weapon to disenfranchise or alienate a minority of the community; +* Binding votes in project decisions; +* Ensure that code committed to the project is either committed under a valid CLA + or is code that was contributed with a clear indication that the Apache License + applied (i.e. small patches submitted to the issue tracker or to the mailing list + are assumed to be submitted with the intent of being covered by the Apache
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Hi Stephen, If anyone wants to look at the resulting Work In Progress document as a whole: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup Thoughts? Big thumbs up to all your changes. Nice work. Some brief comments from a technical perspective: It is self evident that the opportunity for review is much greater if the code is committed to the project's source control as early as possible. Similarly small commits are easier to review than large commits. Technologies like GitHub and Gerrit are making code review extremely easy these days. I am not sure what tools Apache projects use for code review, but in the interest of facilitating such review, I definitely believe that going with the best available *technical* option(s) makes sense, regardless of whether the tool itself is an Apache project. Use what works. The old text said: there is a danger here of falling into a Not Invented Here mentality and I couldn't agree more. The new language is much better, which clearly warns of the consequences of long-running forks while also stating that they may sometimes be useful and/or appropriate. GIT commits can be squashed and history re-written to mask or otherwise hide the source of contributions. True, and it is good to warn about this. However, ultimately I think Git is a better choice (than SVN) because it often makes code review much easier. If a new feature is properly developed on a topic branch with commits squashed, rewritten and organized as needed, the history can be laid out in a very easy-to-understand manner: new features and bugfixes done in properly isolated commits, unit tests added immediately thereafter, etc. If a commit is too large or conflates many different changes, Git provides the tools to split up that work for rereview. Again, thanks for writing this. The new words give me more confidence that Apache has the community's best interest at heart, rather than only Apache for Apache's sake. Regards, Curtis P.S. For those interested, Stephen's changes are more clear when reading the side-by-side diff: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?r1=1507630r2=1509594diff_format=h On Fri, Aug 2, 2013 at 4:59 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have updated the project-roles with my thoughts resulting from the healthy debate on the list and some debates elsewhere. If anyone wants to look at the resulting Work In Progress document as a whole: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup Thoughts? -Stephen -- Forwarded message -- From: steph...@apache.org Date: 2 August 2013 10:52 Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ project-roles.md To: comm...@maven.apache.org Author: stephenc Date: Fri Aug 2 09:52:11 2013 New Revision: 1509594 URL: http://svn.apache.org/r1509594 Log: After a lengthy discussion on the users@maven list and some side discussions on members@apache, I think the following changes are more in line with what we should be seeking as responsibilities of the PMC. * Forks are not bad... letting changes stack up in the fork is bad but more from a 'it will be hard to review' point of view... similarly using a fork to get external contributions complicates the tracablity * We are not obligated to promote other ASF projects... but there should be a symmetry in how that lack of obligation plays out * I identified some more responsibilities of the PMC (if I have missed any, please add) * There is a special case where the PMC Chair can wear the dictators hat... but that is only in the case of unresolvable consensus and the lack of consensus is causing damage to the project and the board is well aware of the issue and expects the chair to put on the dictators hat (with the board watching on) As always, this is a Commit Then Review community... so these changes are being committed for review. Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1509594r1=1509593r2=1509594view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Fri Aug 2 09:52:11 2013 @@ -174,11 +174,31 @@ are kept confidential. The Project Management Committee has the following responsibilities: -* Proposing active contributors for committership, -* Binding votes in project decisions, -* Voting on release artifacts, -* Ensure [Developers Conventions][5] are followed, or updated/improved if necessary, -* !-- TODO: get the rest of these -- +* Active management of those projects
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
On 2 August 2013 16:07, Brian Fox bri...@infinity.nu wrote: I think the bulk of this is pretty good. On the fork section, specifically: As soon as changes in that fork are identified which should be brought back to the project those changes should be introduced into at least a branch hosted on the Apache Maven source control in order to facilitate the easier review by the community. The PMC should encourage by example the early committing of changes from a fork back to Apache Maven source control. This seems to want to compel code to be brought back as a responsibility, I don't think we need to spell that out. This is why I say as soon as ... are identified The wording could be clearer... if somebody can figure out a better way to say it. Basically, as soon as you say something like... Oh commit 1a2b3d4e, we really need to get that into Maven itself, it's too good to be in our fork... you should be trying to hasten getting that commit into Maven itself and if you are on the PMC and one of your commits is one that you say this of... you should just commit it back. Until you realise that a commit is one that you want to push to Maven, hey it's your work... whatever... but as soon as you identify the change as being one that should be at Maven, as a PMC member you are expected to try and get it into Maven quickly so that others working on the fork see that this is the example by which the PMC leads. If you can think of a clearer way to express that than my wording (which since you are not getting my intended meaning must therefore be lacking) please update. The section about the downsides to not doing so and attempting to do it later is really the core of the concerns... the extra diligence required to consume large bodies of work is bigger. That doesn't mean that code contributions are inherently bad just because they were developed elsewhere, it's just harder to pull in. Correct. On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have updated the project-roles with my thoughts resulting from the healthy debate on the list and some debates elsewhere. If anyone wants to look at the resulting Work In Progress document as a whole: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup Thoughts? -Stephen -- Forwarded message -- From: steph...@apache.org Date: 2 August 2013 10:52 Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ project-roles.md To: comm...@maven.apache.org Author: stephenc Date: Fri Aug 2 09:52:11 2013 New Revision: 1509594 URL: http://svn.apache.org/r1509594 Log: After a lengthy discussion on the users@maven list and some side discussions on members@apache, I think the following changes are more in line with what we should be seeking as responsibilities of the PMC. * Forks are not bad... letting changes stack up in the fork is bad but more from a 'it will be hard to review' point of view... similarly using a fork to get external contributions complicates the tracablity * We are not obligated to promote other ASF projects... but there should be a symmetry in how that lack of obligation plays out * I identified some more responsibilities of the PMC (if I have missed any, please add) * There is a special case where the PMC Chair can wear the dictators hat... but that is only in the case of unresolvable consensus and the lack of consensus is causing damage to the project and the board is well aware of the issue and expects the chair to put on the dictators hat (with the board watching on) As always, this is a Commit Then Review community... so these changes are being committed for review. Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1509594r1=1509593r2=1509594view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Fri Aug 2 09:52:11 2013 @@ -174,11 +174,31 @@ are kept confidential. The Project Management Committee has the following responsibilities: -* Proposing active contributors for committership, -* Binding votes in project decisions, -* Voting on release artifacts, -* Ensure [Developers Conventions][5] are followed, or updated/improved if necessary, -* !-- TODO: get the rest of these -- +* Active management of those projects identified by the resolution of the Board + of Directors of the Apache Foundation; +* Ensure the project remains a healthy top-level project of the Apache Foundation + (if a PMC member wants the project to be
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Furthermore, I'd like to see explicit procedural rules on Maven Core and forking. For example, if there's a critical component needing development for Core, and a PMC expresses that such development will be done outside of Apache and then used as a dependency, shouldn't there be a vote on that? On Fri, Aug 2, 2013 at 10:24 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 2 August 2013 16:07, Brian Fox bri...@infinity.nu wrote: I think the bulk of this is pretty good. On the fork section, specifically: As soon as changes in that fork are identified which should be brought back to the project those changes should be introduced into at least a branch hosted on the Apache Maven source control in order to facilitate the easier review by the community. The PMC should encourage by example the early committing of changes from a fork back to Apache Maven source control. This seems to want to compel code to be brought back as a responsibility, I don't think we need to spell that out. This is why I say as soon as ... are identified The wording could be clearer... if somebody can figure out a better way to say it. Basically, as soon as you say something like... Oh commit 1a2b3d4e, we really need to get that into Maven itself, it's too good to be in our fork... you should be trying to hasten getting that commit into Maven itself and if you are on the PMC and one of your commits is one that you say this of... you should just commit it back. Until you realise that a commit is one that you want to push to Maven, hey it's your work... whatever... but as soon as you identify the change as being one that should be at Maven, as a PMC member you are expected to try and get it into Maven quickly so that others working on the fork see that this is the example by which the PMC leads. If you can think of a clearer way to express that than my wording (which since you are not getting my intended meaning must therefore be lacking) please update. The section about the downsides to not doing so and attempting to do it later is really the core of the concerns... the extra diligence required to consume large bodies of work is bigger. That doesn't mean that code contributions are inherently bad just because they were developed elsewhere, it's just harder to pull in. Correct. On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have updated the project-roles with my thoughts resulting from the healthy debate on the list and some debates elsewhere. If anyone wants to look at the resulting Work In Progress document as a whole: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup Thoughts? -Stephen -- Forwarded message -- From: steph...@apache.org Date: 2 August 2013 10:52 Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ project-roles.md To: comm...@maven.apache.org Author: stephenc Date: Fri Aug 2 09:52:11 2013 New Revision: 1509594 URL: http://svn.apache.org/r1509594 Log: After a lengthy discussion on the users@maven list and some side discussions on members@apache, I think the following changes are more in line with what we should be seeking as responsibilities of the PMC. * Forks are not bad... letting changes stack up in the fork is bad but more from a 'it will be hard to review' point of view... similarly using a fork to get external contributions complicates the tracablity * We are not obligated to promote other ASF projects... but there should be a symmetry in how that lack of obligation plays out * I identified some more responsibilities of the PMC (if I have missed any, please add) * There is a special case where the PMC Chair can wear the dictators hat... but that is only in the case of unresolvable consensus and the lack of consensus is causing damage to the project and the board is well aware of the issue and expects the chair to put on the dictators hat (with the board watching on) As always, this is a Commit Then Review community... so these changes are being committed for review. Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1509594r1=1509593r2=1509594view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Fri Aug 2 09:52:11 2013 @@ -174,11 +174,31 @@ are kept confidential. The Project Management Committee has the following responsibilities: -* Proposing
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
On 2 August 2013 16:32, Paul Benedict pbened...@apache.org wrote: Furthermore, I'd like to see explicit procedural rules on Maven Core and forking. For example, if there's a critical component needing development for Core, and a PMC expresses that such development will be done outside of Apache and then used as a dependency, shouldn't there be a vote on that? Votes should be a tool to confirm consensus... not an iron hand. If the consensus of the developers is to use the dependency which is external to the project, then that is fine. If there is no consensus then the dependency will not be introduced. We already have a policy that adding Category B dependencies to Core requires approval of the PMC, I don't see that there is much value in adding even more to this document... but if you can suggest a patch and people agree with it... -Stephen
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Hi Paul, then used as a dependency, shouldn't there be a vote on that? Wouldn't there be a vote for the adoption of any dependency, anyway? Or at least a code review process on the changes that bring in that dependency...? Regards, Curtis On Fri, Aug 2, 2013 at 10:32 AM, Paul Benedict pbened...@apache.org wrote: Furthermore, I'd like to see explicit procedural rules on Maven Core and forking. For example, if there's a critical component needing development for Core, and a PMC expresses that such development will be done outside of Apache and then used as a dependency, shouldn't there be a vote on that? On Fri, Aug 2, 2013 at 10:24 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 2 August 2013 16:07, Brian Fox bri...@infinity.nu wrote: I think the bulk of this is pretty good. On the fork section, specifically: As soon as changes in that fork are identified which should be brought back to the project those changes should be introduced into at least a branch hosted on the Apache Maven source control in order to facilitate the easier review by the community. The PMC should encourage by example the early committing of changes from a fork back to Apache Maven source control. This seems to want to compel code to be brought back as a responsibility, I don't think we need to spell that out. This is why I say as soon as ... are identified The wording could be clearer... if somebody can figure out a better way to say it. Basically, as soon as you say something like... Oh commit 1a2b3d4e, we really need to get that into Maven itself, it's too good to be in our fork... you should be trying to hasten getting that commit into Maven itself and if you are on the PMC and one of your commits is one that you say this of... you should just commit it back. Until you realise that a commit is one that you want to push to Maven, hey it's your work... whatever... but as soon as you identify the change as being one that should be at Maven, as a PMC member you are expected to try and get it into Maven quickly so that others working on the fork see that this is the example by which the PMC leads. If you can think of a clearer way to express that than my wording (which since you are not getting my intended meaning must therefore be lacking) please update. The section about the downsides to not doing so and attempting to do it later is really the core of the concerns... the extra diligence required to consume large bodies of work is bigger. That doesn't mean that code contributions are inherently bad just because they were developed elsewhere, it's just harder to pull in. Correct. On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have updated the project-roles with my thoughts resulting from the healthy debate on the list and some debates elsewhere. If anyone wants to look at the resulting Work In Progress document as a whole: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup Thoughts? -Stephen -- Forwarded message -- From: steph...@apache.org Date: 2 August 2013 10:52 Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ project-roles.md To: comm...@maven.apache.org Author: stephenc Date: Fri Aug 2 09:52:11 2013 New Revision: 1509594 URL: http://svn.apache.org/r1509594 Log: After a lengthy discussion on the users@maven list and some side discussions on members@apache, I think the following changes are more in line with what we should be seeking as responsibilities of the PMC. * Forks are not bad... letting changes stack up in the fork is bad but more from a 'it will be hard to review' point of view... similarly using a fork to get external contributions complicates the tracablity * We are not obligated to promote other ASF projects... but there should be a symmetry in how that lack of obligation plays out * I identified some more responsibilities of the PMC (if I have missed any, please add) * There is a special case where the PMC Chair can wear the dictators hat... but that is only in the case of unresolvable consensus and the lack of consensus is causing damage to the project and the board is well aware of the issue and expects the chair to put on the dictators hat (with the board watching on) As always, this is a Commit Then Review community... so these changes are being committed for review. Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL:
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
On 2 August 2013 16:08, Curtis Rueden ctrue...@wisc.edu wrote: Hi Stephen, If anyone wants to look at the resulting Work In Progress document as a whole: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup Thoughts? Big thumbs up to all your changes. Nice work. Some brief comments from a technical perspective: It is self evident that the opportunity for review is much greater if the code is committed to the project's source control as early as possible. Similarly small commits are easier to review than large commits. Technologies like GitHub and Gerrit are making code review extremely easy these days. I am not sure what tools Apache projects use for code review, but in the interest of facilitating such review, I definitely believe that going with the best available *technical* option(s) makes sense, regardless of whether the tool itself is an Apache project. Use what works. Unfortunately the review must be of what lands at Apache servers. It could be a bare bones review because the bulk of the review happened elsewhere, but there must still be eyes on the code when it lands at Apache at least that is my understanding. The old text said: there is a danger here of falling into a Not Invented Here mentality and I couldn't agree more. The new language is much better, which clearly warns of the consequences of long-running forks while also stating that they may sometimes be useful and/or appropriate. GIT commits can be squashed and history re-written to mask or otherwise hide the source of contributions. True, and it is good to warn about this. However, ultimately I think Git is a better choice (than SVN) because it often makes code review much easier. SVN history can be rewritten if you have admin access to the Subversion server... SVN revision properties can be edited to, e.g. change author or commit message, etc. This is not just a GIT issue, this is a not happening at Apache hardware issue... when it happens at Apache hardware, we can be more lax about probing for those kind of issues as we have the excuse that we rely on infra to put in place the controls to ensure the required traceability... when it happens on 3rd party controlled hardware, we don't have that option, so the review needs to be more strict. If a new feature is properly developed on a topic branch with commits squashed, rewritten and organized as needed, the history can be laid out in a very easy-to-understand manner: new features and bugfixes done in properly isolated commits, unit tests added immediately thereafter, etc. If a commit is too large or conflates many different changes, Git provides the tools to split up that work for rereview. Yes, and I don't think anyone was suggesting we move away from GIT... if anything we are migrating our repositories from Subversion to GIT because it is the better tool. Again, thanks for writing this. The new words give me more confidence that Apache has the community's best interest at heart, rather than only Apache for Apache's sake. Keep in mind that there will always be some things that we need to do in slightly strange ways because we need to maintain the legal protection that the foundation provides for Committers... but keep in mind that none of us enjoy that!!! Regards, Curtis P.S. For those interested, Stephen's changes are more clear when reading the side-by-side diff: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?r1=1507630r2=1509594diff_format=h On Fri, Aug 2, 2013 at 4:59 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have updated the project-roles with my thoughts resulting from the healthy debate on the list and some debates elsewhere. If anyone wants to look at the resulting Work In Progress document as a whole: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup Thoughts? -Stephen -- Forwarded message -- From: steph...@apache.org Date: 2 August 2013 10:52 Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ project-roles.md To: comm...@maven.apache.org Author: stephenc Date: Fri Aug 2 09:52:11 2013 New Revision: 1509594 URL: http://svn.apache.org/r1509594 Log: After a lengthy discussion on the users@maven list and some side discussions on members@apache, I think the following changes are more in line with what we should be seeking as responsibilities of the PMC. * Forks are not bad... letting changes stack up in the fork is bad but more from a 'it will be hard to review' point of view... similarly using a fork to get external contributions complicates the tracablity * We are not obligated to promote other ASF projects... but there should be a symmetry in how that lack of obligation plays out * I identified some more
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Le vendredi 2 août 2013 10:08:42 Curtis Rueden a écrit : True, and it is good to warn about this. However, ultimately I think Git is a better choice (than SVN) because it often makes code review much easier. I didn't use gerrit nor have seen anybody using it. But I hear about it more and more often as an argument why it makes git better than svn (even if I read that gerrit is a fork of rietveld, which is the same for subversion: but nobody even talks about it, don't know why). Is this pure theory? a dream? a reality for a minority of experts, talking about it loudly but no mere mortal can use it? (intentional provocational tone to motivate people who know to show me the direction to the light :) ) If a new feature is properly developed on a topic branch with commits squashed, rewritten and organized as needed, the history can be laid out in a very easy-to-understand manner: new features and bugfixes done in properly isolated commits, unit tests added immediately thereafter, etc. yes, with git, you can: with git, so much things can be done. But once again, I didn't see anybody do it, because it's a lot of work. And it requires to be a git black belt. For the moment, just making a rebase before merging a branch seems hard for us mere mortals. If a commit is too large or conflates many different changes, Git provides the tools to split up that work for rereview. Again, thanks for writing this. +1 I like it too Regards, Hervé - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
I don't understand the iron hand analogy. I was expressing the use of a vote to allow or disallow critical development outside of Apache. The vote would lead to a consensus, no? On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 2 August 2013 16:32, Paul Benedict pbened...@apache.org wrote: Furthermore, I'd like to see explicit procedural rules on Maven Core and forking. For example, if there's a critical component needing development for Core, and a PMC expresses that such development will be done outside of Apache and then used as a dependency, shouldn't there be a vote on that? Votes should be a tool to confirm consensus... not an iron hand. If the consensus of the developers is to use the dependency which is external to the project, then that is fine. If there is no consensus then the dependency will not be introduced. We already have a policy that adding Category B dependencies to Core requires approval of the PMC, I don't see that there is much value in adding even more to this document... but if you can suggest a patch and people agree with it... -Stephen -- Cheers, Paul
skinny WAR classpath includes timestamped entries for SNAPSHOT dependenencies
I have a large, multi-module project that includes WAR and EAR projects. We are using skinny WARs inside the EAR. I'm seeing a problem where the WAR manifest has timestamped classpath entries (e,g, research-jpa-1.0.0-20130802.22-177.jar) but the EAR contains SNAPSHOT files (e.g. research-jpa-1.0.0-SNAPSHOT.jar). This only appears to happen if the dependencies (research-jpa in this example) are retrieved from the remote repo. The problem goes away if I mvn install the research-jpa project before building the WAR project. Is there a work-around for this problem? Is it a known issue or should I open a JIRA for it? If I should open one, would it be against the WAR plugin or the archiver? If it matters we're using Maven 3.0.5, war-plugin 2.4, ear-plugin 2.8 Jeffrey E. (Jeff) Care Advisory Software Engineer | IBM Watson Solutions Release Engineering email: ca...@us.ibm.com | External: 919-543-4907 | Tie line: 441-4907
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
We cannot stop somebody from developing something outside of Apache. So I could go off and write a High Performance Logging API... now I could be doing that because I want to foist that Logging API on Maven... or I could be doing it as an experiment that, if successful, I may offer for Maven to consume... or I could be doing it because I need it for my Day Job... We cannot know the reasons why somebody is doing something outside of Maven... we can ask, but we cannot *know* if the answer we are given is truthful. So anyway, I now have this ultra whizzbang high performance logging API and I am aware of some deficit in the logging performance of Maven, so I spin up a private fork (it could be a hidden private fork, or it could be a public one... doesn't matter) and integrate the logging API and low and behold I see a whopping X% improvement... so I want to bring that back to Maven... Is there anything wrong with the above? If the library I created is under a Category A license and open source and I go with CTR and nobody vetos my commit... we have consensus... why do we need to go all Iron Fist and require a vote? We already have established tools: review of commits, vetos on commits, mandatory votes for Category B dependencies... Do we really need *more* processes and procedures to follow? On 2 August 2013 16:51, Paul Benedict pbened...@apache.org wrote: I don't understand the iron hand analogy. I was expressing the use of a vote to allow or disallow critical development outside of Apache. The vote would lead to a consensus, no? On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 2 August 2013 16:32, Paul Benedict pbened...@apache.org wrote: Furthermore, I'd like to see explicit procedural rules on Maven Core and forking. For example, if there's a critical component needing development for Core, and a PMC expresses that such development will be done outside of Apache and then used as a dependency, shouldn't there be a vote on that? Votes should be a tool to confirm consensus... not an iron hand. If the consensus of the developers is to use the dependency which is external to the project, then that is fine. If there is no consensus then the dependency will not be introduced. We already have a policy that adding Category B dependencies to Core requires approval of the PMC, I don't see that there is much value in adding even more to this document... but if you can suggest a patch and people agree with it... -Stephen -- Cheers, Paul
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Hi Herve, I didn't use gerrit nor have seen anybody using it. ... Is this pure theory? a dream? a reality for a minority of experts, talking about it loudly but no mere mortal can use it? Google uses it (of course). For example, for Chromium: https://gerrit.chromium.org/ Kitware uses it. ITK, VTK, etc.: http://review.source.kitware.com/ I'm sure there are many others. Personally my colleagues and I don't use it; we use GitHub's code review mechanism which is simple and effective. You can comment on any Pull Request, and on any line of any commit. I hear about it more and more often as an argument why it makes git better than svn It was not my goal to argue that Gerrit makes Git better than SVN but rather than good code review tools make code review *much* easier. Git is better than SVN for many, many reasons that have nothing to do with code review tools. :-P yes, with git, you can: with git, so much things can be done. But once again, I didn't see anybody do it, because it's a lot of work. And it requires to be a git black belt. As a programmer, revision control in one of your bread-and-butter tools. Shouldn't you be taking the time to become a VCS black belt? Doing so will save you loads of time in the long run, for the same reasons that becoming a command line master, or an IDE master, or a master of *any* effective productivity tool, will. Embrace Larry Wall's virtues of the programmer -- laziness, impatience and hubris -- and always seek the better, faster path! Computers are different than other skill sets: a professional sprinter may be able to sprint 2x or 3x or even 5x faster than you, but a professional programmer can accomplish a task on a computer thousands or even millions of times faster than a neophyte... *if* the programmer has a thirst for knowledge and self-improvement. /soapbox Anyway, yes, my colleagues and I *do* use Git in this way: work on topic branches, rewrite history to make review easier, and sometimes file Pull Requests on GitHub to specifically invite review for possibly disruptive changes. I'm not really sure what to point you at here, other than the Contribution Activity section of my GitHub page: https://github.com/ctrueden Of course, it is changing all the time... Regards, Curtis On Fri, Aug 2, 2013 at 10:47 AM, Hervé BOUTEMY herve.bout...@free.frwrote: Le vendredi 2 août 2013 10:08:42 Curtis Rueden a écrit : True, and it is good to warn about this. However, ultimately I think Git is a better choice (than SVN) because it often makes code review much easier. I didn't use gerrit nor have seen anybody using it. But I hear about it more and more often as an argument why it makes git better than svn (even if I read that gerrit is a fork of rietveld, which is the same for subversion: but nobody even talks about it, don't know why). Is this pure theory? a dream? a reality for a minority of experts, talking about it loudly but no mere mortal can use it? (intentional provocational tone to motivate people who know to show me the direction to the light :) ) If a new feature is properly developed on a topic branch with commits squashed, rewritten and organized as needed, the history can be laid out in a very easy-to-understand manner: new features and bugfixes done in properly isolated commits, unit tests added immediately thereafter, etc. yes, with git, you can: with git, so much things can be done. But once again, I didn't see anybody do it, because it's a lot of work. And it requires to be a git black belt. For the moment, just making a rebase before merging a branch seems hard for us mere mortals. If a commit is too large or conflates many different changes, Git provides the tools to split up that work for rereview. Again, thanks for writing this. +1 I like it too Regards, Hervé - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: skinny WAR classpath includes timestamped entries for SNAPSHOT dependenencies
Is there a work-around for this problem? Is it a known issue or should I You mean other than this work-around that you already found?? example) are retrieved from the remote repo. The problem goes away if I mvn install the research-jpa project before building the WAR project. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
On Fri, Aug 2, 2013 at 12:10 PM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: So anyway, I now have this ultra whizzbang high performance logging API and I am aware of some deficit in the logging performance of Maven, so I spin up a private fork (it could be a hidden private fork, or it could be a public one... doesn't matter) and integrate the logging API and low and behold I see a whopping X% improvement... so I want to bring that back to Maven... Is there anything wrong with the above? I say absolutely not. Where things can go wrong is what happens next. If someone commits that giant chunk with no discussion, then that's probably going to raise concerns. If instead a discussion is started to discuss the work and decide if it's appropriate to pull in, then fine. - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
I've stated from the beginning of this thread that it's impossible to prevent someone from developing outside of Apache. I stand by that still. That can't be prevented and any attempt will fail since it's not practical. If my words today aren't clear, I'll try again. My stance isn't about halting developing elsewhere, but to halt what I (and maybe some others) perceive as a way of getting around the Apache community. I won't use your ultra whizzbang high performance logging :-) example because it doesn't fit what my concern; but imagine an existing component (I won't name any) that is critical and Maven's existence and Maven can't function without it. It's very easy for any PMC member to go to another OSS community, develop it, and then kind of leave the other PMCs with no real choice but to use it because the code realizes the future of Maven. Those other PMCs are really backed into a corner; they have no real recourse to preventing this, lest Maven development is simply halted altogether. The other OSS community has other committers, other mailing lists, other deliberations, etc. Community work and input becomes marginalized here. Does this make sense to you? That kind of community-splitting effort needs to stop and that's what I am trying to address. Cheers, Paul On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We cannot stop somebody from developing something outside of Apache. So I could go off and write a High Performance Logging API... now I could be doing that because I want to foist that Logging API on Maven... or I could be doing it as an experiment that, if successful, I may offer for Maven to consume... or I could be doing it because I need it for my Day Job... We cannot know the reasons why somebody is doing something outside of Maven... we can ask, but we cannot *know* if the answer we are given is truthful. So anyway, I now have this ultra whizzbang high performance logging API and I am aware of some deficit in the logging performance of Maven, so I spin up a private fork (it could be a hidden private fork, or it could be a public one... doesn't matter) and integrate the logging API and low and behold I see a whopping X% improvement... so I want to bring that back to Maven... Is there anything wrong with the above? If the library I created is under a Category A license and open source and I go with CTR and nobody vetos my commit... we have consensus... why do we need to go all Iron Fist and require a vote? We already have established tools: review of commits, vetos on commits, mandatory votes for Category B dependencies... Do we really need *more* processes and procedures to follow? On 2 August 2013 16:51, Paul Benedict pbened...@apache.org wrote: I don't understand the iron hand analogy. I was expressing the use of a vote to allow or disallow critical development outside of Apache. The vote would lead to a consensus, no? On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 2 August 2013 16:32, Paul Benedict pbened...@apache.org wrote: Furthermore, I'd like to see explicit procedural rules on Maven Core and forking. For example, if there's a critical component needing development for Core, and a PMC expresses that such development will be done outside of Apache and then used as a dependency, shouldn't there be a vote on that? Votes should be a tool to confirm consensus... not an iron hand. If the consensus of the developers is to use the dependency which is external to the project, then that is fine. If there is no consensus then the dependency will not be introduced. We already have a policy that adding Category B dependencies to Core requires approval of the PMC, I don't see that there is much value in adding even more to this document... but if you can suggest a patch and people agree with it... -Stephen -- Cheers, Paul -- Cheers, Paul
Re: skinny WAR classpath includes timestamped entries for SNAPSHOT dependenencies
Wayne Fay wayne...@gmail.com wrote on 08/02/2013 12:24:14 PM: Is there a work-around for this problem? Is it a known issue or should I You mean other than this work-around that you already found?? example) are retrieved from the remote repo. The problem goes awayif I mvn install the research-jpa project before building the WAR project. Yes, sorry I wasn't clear. I don't want developers who never have to touch research-jpa to be forced to build that project everyday. I was thinking more along the lines of some sort of POM hack...
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Line 238, 246 opertunity - opportunity I wonder if a statement of policy should have so much procedure written into it. The procedures will change over time as people change their ideas about best practices whereas policies should be less volatile. It might be easier to state the goals of the policy and leave the implementation up to a more informal discussion that takes the actual situation into account. Ron On 02/08/2013 11:07 AM, Brian Fox wrote: I think the bulk of this is pretty good. On the fork section, specifically: As soon as changes in that fork are identified which should be brought back to the project those changes should be introduced into at least a branch hosted on the Apache Maven source control in order to facilitate the easier review by the community. The PMC should encourage by example the early committing of changes from a fork back to Apache Maven source control. This seems to want to compel code to be brought back as a responsibility, I don't think we need to spell that out. The section about the downsides to not doing so and attempting to do it later is really the core of the concerns... the extra diligence required to consume large bodies of work is bigger. That doesn't mean that code contributions are inherently bad just because they were developed elsewhere, it's just harder to pull in. On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have updated the project-roles with my thoughts resulting from the healthy debate on the list and some debates elsewhere. If anyone wants to look at the resulting Work In Progress document as a whole: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup Thoughts? -Stephen -- Forwarded message -- From: steph...@apache.org Date: 2 August 2013 10:52 Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ project-roles.md To: comm...@maven.apache.org Author: stephenc Date: Fri Aug 2 09:52:11 2013 New Revision: 1509594 URL: http://svn.apache.org/r1509594 Log: After a lengthy discussion on the users@maven list and some side discussions on members@apache, I think the following changes are more in line with what we should be seeking as responsibilities of the PMC. * Forks are not bad... letting changes stack up in the fork is bad but more from a 'it will be hard to review' point of view... similarly using a fork to get external contributions complicates the tracablity * We are not obligated to promote other ASF projects... but there should be a symmetry in how that lack of obligation plays out * I identified some more responsibilities of the PMC (if I have missed any, please add) * There is a special case where the PMC Chair can wear the dictators hat... but that is only in the case of unresolvable consensus and the lack of consensus is causing damage to the project and the board is well aware of the issue and expects the chair to put on the dictators hat (with the board watching on) As always, this is a Commit Then Review community... so these changes are being committed for review. Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1509594r1=1509593r2=1509594view=diff == --- maven/site/trunk/content/markdown/project-roles.md (original) +++ maven/site/trunk/content/markdown/project-roles.md Fri Aug 2 09:52:11 2013 @@ -174,11 +174,31 @@ are kept confidential. The Project Management Committee has the following responsibilities: -* Proposing active contributors for committership, -* Binding votes in project decisions, -* Voting on release artifacts, -* Ensure [Developers Conventions][5] are followed, or updated/improved if necessary, -* !-- TODO: get the rest of these -- +* Active management of those projects identified by the resolution of the Board + of Directors of the Apache Foundation; +* Ensure the project remains a healthy top-level project of the Apache Foundation + (if a PMC member wants the project to be hosted elsewhere they should resign + from the PMC stating their reason - if the PMC shrinks beyond the minimal viable + size then as a result of a desire by the bulk of the PMC to move the project + elsewhere, the Board of the Apache Foundation will take that into account + when moving the project into the Foundation's Attic) +* Prepare reports as required by the Board of the Apache Foundation and + ensure those reports are ready for presentation by the PMC Chair in a timely + manner; +* Defend the trademarks belonging to the project; +* Proposing active contributors for committership; +* Ensure that votes in the community are used as a tool to establish consensus + and not a weapon to disenfranchise or alienate a
Re: skinny WAR classpath includes timestamped entries for SNAPSHOT dependenencies
Yes, sorry I wasn't clear. I don't want developers who never have to touch research-jpa to be forced to build that project everyday. I was thinking more along the lines of some sort of POM hack... Maven is diametrically opposed to hacks. If there is a good solution to your problem, it should not involve a hack. But there may not (today) be a good solution to your problem (yet). I'm not certain as I haven't been using skinny wars (or ears) lately. Hopefully someone else will pipe up. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
thank you Curtis: all the pointers you gave are of great value! I perfectly understand your Githubs examples: pull requests + work to give pull requests most chances to be accepted In fact, in our case, for somebody having commit privileges, using such pull requests isn't the first thing I would have thought, but yes, it is a good Review Then Commit tooling For somebody with commit privileges, would you find any key difference with a branch on ASF Git + discussion on mailing list before merging into master? For gerrit, now I see what it looks like: seems really more complex than GitHubs pull requests. Don't know when such tooling starts to be really useful Thanks again for your pointers: today, I learned something useful, it's a good day Notice I'm having holidays and won't be on the ML for 2 weeks: I won't be able to continue the discussion, even if really instructive Regards, Hervé Le vendredi 2 août 2013 11:13:50 Curtis Rueden a écrit : Hi Herve, I didn't use gerrit nor have seen anybody using it. ... Is this pure theory? a dream? a reality for a minority of experts, talking about it loudly but no mere mortal can use it? Google uses it (of course). For example, for Chromium: https://gerrit.chromium.org/ Kitware uses it. ITK, VTK, etc.: http://review.source.kitware.com/ I'm sure there are many others. Personally my colleagues and I don't use it; we use GitHub's code review mechanism which is simple and effective. You can comment on any Pull Request, and on any line of any commit. I hear about it more and more often as an argument why it makes git better than svn It was not my goal to argue that Gerrit makes Git better than SVN but rather than good code review tools make code review *much* easier. Git is better than SVN for many, many reasons that have nothing to do with code review tools. :-P yes, with git, you can: with git, so much things can be done. But once again, I didn't see anybody do it, because it's a lot of work. And it requires to be a git black belt. As a programmer, revision control in one of your bread-and-butter tools. Shouldn't you be taking the time to become a VCS black belt? Doing so will save you loads of time in the long run, for the same reasons that becoming a command line master, or an IDE master, or a master of *any* effective productivity tool, will. Embrace Larry Wall's virtues of the programmer -- laziness, impatience and hubris -- and always seek the better, faster path! Computers are different than other skill sets: a professional sprinter may be able to sprint 2x or 3x or even 5x faster than you, but a professional programmer can accomplish a task on a computer thousands or even millions of times faster than a neophyte... *if* the programmer has a thirst for knowledge and self-improvement. /soapbox Anyway, yes, my colleagues and I *do* use Git in this way: work on topic branches, rewrite history to make review easier, and sometimes file Pull Requests on GitHub to specifically invite review for possibly disruptive changes. I'm not really sure what to point you at here, other than the Contribution Activity section of my GitHub page: https://github.com/ctrueden Of course, it is changing all the time... Regards, Curtis On Fri, Aug 2, 2013 at 10:47 AM, Hervé BOUTEMY herve.bout...@free.frwrote: Le vendredi 2 août 2013 10:08:42 Curtis Rueden a écrit : True, and it is good to warn about this. However, ultimately I think Git is a better choice (than SVN) because it often makes code review much easier. I didn't use gerrit nor have seen anybody using it. But I hear about it more and more often as an argument why it makes git better than svn (even if I read that gerrit is a fork of rietveld, which is the same for subversion: but nobody even talks about it, don't know why). Is this pure theory? a dream? a reality for a minority of experts, talking about it loudly but no mere mortal can use it? (intentional provocational tone to motivate people who know to show me the direction to the light :) ) If a new feature is properly developed on a topic branch with commits squashed, rewritten and organized as needed, the history can be laid out in a very easy-to-understand manner: new features and bugfixes done in properly isolated commits, unit tests added immediately thereafter, etc. yes, with git, you can: with git, so much things can be done. But once again, I didn't see anybody do it, because it's a lot of work. And it requires to be a git black belt. For the moment, just making a rebase before merging a branch seems hard for us mere mortals. If a commit is too large or conflates many different changes, Git provides the tools to split up that work for rereview. Again, thanks for writing this. +1 I like it too Regards, Hervé
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
On 02/08/2013 12:29 PM, Paul Benedict wrote: I've stated from the beginning of this thread that it's impossible to prevent someone from developing outside of Apache. I stand by that still. That can't be prevented and any attempt will fail since it's not practical. If my words today aren't clear, I'll try again. My stance isn't about halting developing elsewhere, but to halt what I (and maybe some others) perceive as a way of getting around the Apache community. I won't use your ultra whizzbang high performance logging :-) example because it doesn't fit what my concern; but imagine an existing component (I won't name any) that is critical and Maven's existence and Maven can't function without it. It's very easy for any PMC member to go to another OSS community, develop it, and then kind of leave the other PMCs with no real choice but to use it because the code realizes the future of Maven. Those other PMCs are really backed into a corner; they have no real recourse to preventing this, lest Maven development is simply halted altogether. The other OSS community has other committers, other mailing lists, other deliberations, etc. Community work and input becomes marginalized here. Does this make sense to you? That kind of community-splitting effort needs to stop and that's what I am trying to address. The Maven group can always port the code back into the Maven project if the other project is OSS. If it has gone to a proprietary project (lots of open source stuff goes that way too), then the Apache maven team will have to invent its own future to be better or the same as the alternative future. Not sure how this could happen in real life. It sounds like the future of Maven resided in the head of one person who felt that the Apache Maven project did not have room for its own future so he moved on to a team that wanted to make the future happen now. That would appear to be a good thing for Maven users. The users adopt to this new project and enjoy the future. The Apache project members who see the future as a good thing move to the new group and the people who did not want to support the future keep supporting the old way. This would not be the first project that died rather than innovate. You can't write a policy that protects against this and still stays open source. You have no way to stop this from happening nor should you try. Ron Cheers, Paul On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We cannot stop somebody from developing something outside of Apache. So I could go off and write a High Performance Logging API... now I could be doing that because I want to foist that Logging API on Maven... or I could be doing it as an experiment that, if successful, I may offer for Maven to consume... or I could be doing it because I need it for my Day Job... We cannot know the reasons why somebody is doing something outside of Maven... we can ask, but we cannot *know* if the answer we are given is truthful. So anyway, I now have this ultra whizzbang high performance logging API and I am aware of some deficit in the logging performance of Maven, so I spin up a private fork (it could be a hidden private fork, or it could be a public one... doesn't matter) and integrate the logging API and low and behold I see a whopping X% improvement... so I want to bring that back to Maven... Is there anything wrong with the above? If the library I created is under a Category A license and open source and I go with CTR and nobody vetos my commit... we have consensus... why do we need to go all Iron Fist and require a vote? We already have established tools: review of commits, vetos on commits, mandatory votes for Category B dependencies... Do we really need *more* processes and procedures to follow? On 2 August 2013 16:51, Paul Benedict pbened...@apache.org wrote: I don't understand the iron hand analogy. I was expressing the use of a vote to allow or disallow critical development outside of Apache. The vote would lead to a consensus, no? On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 2 August 2013 16:32, Paul Benedict pbened...@apache.org wrote: Furthermore, I'd like to see explicit procedural rules on Maven Core and forking. For example, if there's a critical component needing development for Core, and a PMC expresses that such development will be done outside of Apache and then used as a dependency, shouldn't there be a vote on that? Votes should be a tool to confirm consensus... not an iron hand. If the consensus of the developers is to use the dependency which is external to the project, then that is fine. If there is no consensus then the dependency will not be introduced. We already have a policy that adding Category B dependencies to Core requires approval of the PMC, I don't see that there is much value in adding even more to this document... but if you can suggest a patch
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
On 02/08/2013 11:32 AM, Paul Benedict wrote: Furthermore, I'd like to see explicit procedural rules on Maven Core and forking. For example, if there's a critical component needing development for Core, and a PMC expresses that such development will be done outside of Apache and then used as a dependency, shouldn't there be a vote on that? For what purpose? You can't stop the person anyway and in the discussion, it is fair to assume that you would have raised your objections. The vote will come when a PMC member wants to change the dependency when the code comes back. At that point you have the code and you have a chance to see the new functionality or performance to see if the changes live up to the advanced billing. Ron On Fri, Aug 2, 2013 at 10:24 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 2 August 2013 16:07, Brian Fox bri...@infinity.nu wrote: I think the bulk of this is pretty good. On the fork section, specifically: As soon as changes in that fork are identified which should be brought back to the project those changes should be introduced into at least a branch hosted on the Apache Maven source control in order to facilitate the easier review by the community. The PMC should encourage by example the early committing of changes from a fork back to Apache Maven source control. This seems to want to compel code to be brought back as a responsibility, I don't think we need to spell that out. This is why I say as soon as ... are identified The wording could be clearer... if somebody can figure out a better way to say it. Basically, as soon as you say something like... Oh commit 1a2b3d4e, we really need to get that into Maven itself, it's too good to be in our fork... you should be trying to hasten getting that commit into Maven itself and if you are on the PMC and one of your commits is one that you say this of... you should just commit it back. Until you realise that a commit is one that you want to push to Maven, hey it's your work... whatever... but as soon as you identify the change as being one that should be at Maven, as a PMC member you are expected to try and get it into Maven quickly so that others working on the fork see that this is the example by which the PMC leads. If you can think of a clearer way to express that than my wording (which since you are not getting my intended meaning must therefore be lacking) please update. The section about the downsides to not doing so and attempting to do it later is really the core of the concerns... the extra diligence required to consume large bodies of work is bigger. That doesn't mean that code contributions are inherently bad just because they were developed elsewhere, it's just harder to pull in. Correct. On Fri, Aug 2, 2013 at 5:59 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: I have updated the project-roles with my thoughts resulting from the healthy debate on the list and some debates elsewhere. If anyone wants to look at the resulting Work In Progress document as a whole: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?revision=1509594view=markup Thoughts? -Stephen -- Forwarded message -- From: steph...@apache.org Date: 2 August 2013 10:52 Subject: svn commit: r1509594 - /maven/site/trunk/content/markdown/ project-roles.md To: comm...@maven.apache.org Author: stephenc Date: Fri Aug 2 09:52:11 2013 New Revision: 1509594 URL: http://svn.apache.org/r1509594 Log: After a lengthy discussion on the users@maven list and some side discussions on members@apache, I think the following changes are more in line with what we should be seeking as responsibilities of the PMC. * Forks are not bad... letting changes stack up in the fork is bad but more from a 'it will be hard to review' point of view... similarly using a fork to get external contributions complicates the tracablity * We are not obligated to promote other ASF projects... but there should be a symmetry in how that lack of obligation plays out * I identified some more responsibilities of the PMC (if I have missed any, please add) * There is a special case where the PMC Chair can wear the dictators hat... but that is only in the case of unresolvable consensus and the lack of consensus is causing damage to the project and the board is well aware of the issue and expects the chair to put on the dictators hat (with the board watching on) As always, this is a Commit Then Review community... so these changes are being committed for review. Modified: maven/site/trunk/content/markdown/project-roles.md Modified: maven/site/trunk/content/markdown/project-roles.md URL: http://svn.apache.org/viewvc/maven/site/trunk/content/markdown/project-roles.md?rev=1509594r1=1509593r2=1509594view=diff == --- maven/site/trunk/content/markdown/project-roles.md
Trouble with custom titlepages using Maven docbkx plugin to generate output
Hi, all, I hope someone out there has some tips for me regarding this very confusing issue I've encountered when I try to generate my HTML output from the context of the Eclipse Maven docbkx plugin. In my customization layer I have an import statement to use the custom titlepage I generated as per the usual method as described in Bob Stayton's guide. If I run the Maven build, it fails with this error on parsing that file: Error at div on line 1838 my custom titlepage file: No attribute-set exists named topic.titlepage.recto.style If I comment out the import statement, it builds fine with the default titlepage settings. But I don't *want* the default titlepage setting - that's why I generated a customized one. Looking through the DocBook distribution, I located that attribute set defined in the file titlepage.xsl in each of the transformation directories. The definition is simple an attribute set with nothing in it. So I thought that if I copied that attrtibute-set elemtn into my customization layer, things should work. Well, they do - sort of. I get a file with nothing in the top of the page at all where the pieces the titlepage XSL creates usually appear - the document title and some other specified metadata. Outside of Eclipse, if I run the usual command-line transformations, everything works just like it should. I suspect there's something I'm not understanding about how the docbkx plugin accesses the DocBook XSL files, or about how the general transformation is calling the titlepage XSL file. Any clues from anyone that might have gone this way before? Thanks! Alan -- Alan C. Oehler Senior Technical Writer | Instart Logic M: 650.504.7003 www.instartlogic.com
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Le 2 août 2013 17:48, Hervé BOUTEMY herve.bout...@free.fr a écrit : Le vendredi 2 août 2013 10:08:42 Curtis Rueden a écrit : True, and it is good to warn about this. However, ultimately I think Git is a better choice (than SVN) because it often makes code review much easier. I didn't use gerrit nor have seen anybody using it. But I hear about it more and more often as an argument why it makes git better than svn (even if I read that gerrit is a fork of rietveld, which is the same for subversion: but nobody even talks about it, don't know why). Is this pure theory? a dream? a reality for a minority of experts, talking about it loudly but no mere mortal can use it? (intentional provocational tone to motivate people who know to show me the direction to the light :) ) Just my 2 cents : been using gerrit professionally on a daily basis for 8 months now. So there's actually real people using it, I can testify ;). We're a team of ~10 guys. (For French savvy people I've given a short talk about it at the Toulouse jug. The session was recorded ans is hosted on parleys). If a new feature is properly developed on a topic branch with commits squashed, rewritten and organized as needed, the history can be laid out in a very easy-to-understand manner: new features and bugfixes done in properly isolated commits, unit tests added immediately thereafter, etc. yes, with git, you can: with git, so much things can be done. But once again, I didn't see anybody do it, because it's a lot of work. You're right. I try to do it as often as I can. But perfection takes a bit too long to commit/rework and sometimes it's ridiculous ;). And it requires to be a git black belt. It helps to practice, sure. Btw, Gerrit makes it worse. It almost forces you to use advances features to make it really useful. That's why I'd say putting a whole team both beginning with git and gerrit would be a mistake. For the moment, just making a rebase before merging a branch seems hard for us mere mortals. If a commit is too large or conflates many different changes, Git provides the tools to split up that work for rereview. Again, thanks for writing this. +1 I like it too Regards, Hervé - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
Le 2 août 2013 20:27, Baptiste MATHUS m...@batmat.net a écrit : Le 2 août 2013 17:48, Hervé BOUTEMY herve.bout...@free.fr a écrit : Le vendredi 2 août 2013 10:08:42 Curtis Rueden a écrit : True, and it is good to warn about this. However, ultimately I think Git is a better choice (than SVN) because it often makes code review much easier. I didn't use gerrit nor have seen anybody using it. But I hear about it more and more often as an argument why it makes git better than svn (even if I read that gerrit is a fork of rietveld, which is the same for subversion: but nobody even talks about it, don't know why). Is this pure theory? a dream? a reality for a minority of experts, talking about it loudly but no mere mortal can use it? (intentional provocational tone to motivate people who know to show me the direction to the light :) ) Just my 2 cents : been using gerrit professionally on a daily basis for 8 months now. So there's actually real people using it, I can testify ;). We're a team of ~10 guys. (For French savvy people I've given a short talk about it at the Toulouse jug. The session was recorded ans is hosted on parleys). If a new feature is properly developed on a topic branch with commits squashed, rewritten and organized as needed, the history can be laid out in a very easy-to-understand manner: new features and bugfixes done in properly isolated commits, unit tests added immediately thereafter, etc. yes, with git, you can: with git, so much things can be done. But once again, I didn't see anybody do it, because it's a lot of work. You're right. I try to do it as often as I can. But perfection takes a bit too long to commit/rework and sometimes it's ridiculous ;). Oops not sure I was clear. I was answering to 'lot of work's part. Not 'anybody...' because I actually do it and know many people doing it very often. I generally do it almost each time before pushing. And it requires to be a git black belt. It helps to practice, sure. Btw, Gerrit makes it worse. It almost forces you to use advances features to make it really useful. That's why I'd say putting a whole team both beginning with git and gerrit would be a mistake. For the moment, just making a rebase before merging a branch seems hard for us mere mortals. If a commit is too large or conflates many different changes, Git provides the tools to split up that work for rereview. Again, thanks for writing this. +1 I like it too Regards, Hervé - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: skinny WAR classpath includes timestamped entries for SNAPSHOT dependenencies
We use the skinny wars / ear and never had this issue. Maybe a dependency issue with your poms? It may sound stupid, but did you take a look at the dependency tree to make sure the resolution was OK ? On Aug 2, 2013 1:18 PM, Wayne Fay wayne...@gmail.com wrote: Yes, sorry I wasn't clear. I don't want developers who never have to touch research-jpa to be forced to build that project everyday. I was thinking more along the lines of some sort of POM hack... Maven is diametrically opposed to hacks. If there is a good solution to your problem, it should not involve a hack. But there may not (today) be a good solution to your problem (yet). I'm not certain as I haven't been using skinny wars (or ears) lately. Hopefully someone else will pipe up. Wayne - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
Re: [DISCUSS] On the Maven PMC roles... (was [DISCUSS] Should the Maven PMC be an example of how we want the Maven Community to behave...)
On Aug 2, 2013, at 12:30 PM, Paul Benedict pbened...@apache.org wrote: I've stated from the beginning of this thread that it's impossible to prevent someone from developing outside of Apache. I stand by that still. That can't be prevented and any attempt will fail since it's not practical. If my words today aren't clear, I'll try again. My stance isn't about halting developing elsewhere, but to halt what I (and maybe some others) perceive as a way of getting around the Apache community. I won't use your ultra whizzbang high performance logging :-) example because it doesn't fit what my concern; but imagine an existing component (I won't name any) that is critical and Maven's existence and Maven can't function without it. It's very easy for any PMC member to go to another OSS community, develop it, and then kind of leave the other PMCs with no real choice but to use it because the code realizes the future of Maven. Those other PMCs are really backed into a corner; they have no real recourse to preventing this, lest Maven development is simply halted altogether. The other OSS community has other committers, other mailing lists, other deliberations, etc. Community work and input becomes marginalized here. Does this make sense to you? That kind of community-splitting effort needs to stop and that's what I am trying to address. The cat b / core pmc rule was already adopted to address cases like this. The pmc voted to allow the previous cases so its not like anything magical happened here. I don't think we need to be overly broad to spell out every operating rule in the roles and responsibilities. Keeping tabs on situations like that is exactly the role of the pmc and I believe the document covers that sufficiently. Cheers, Paul On Fri, Aug 2, 2013 at 11:10 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: We cannot stop somebody from developing something outside of Apache. So I could go off and write a High Performance Logging API... now I could be doing that because I want to foist that Logging API on Maven... or I could be doing it as an experiment that, if successful, I may offer for Maven to consume... or I could be doing it because I need it for my Day Job... We cannot know the reasons why somebody is doing something outside of Maven... we can ask, but we cannot *know* if the answer we are given is truthful. So anyway, I now have this ultra whizzbang high performance logging API and I am aware of some deficit in the logging performance of Maven, so I spin up a private fork (it could be a hidden private fork, or it could be a public one... doesn't matter) and integrate the logging API and low and behold I see a whopping X% improvement... so I want to bring that back to Maven... Is there anything wrong with the above? If the library I created is under a Category A license and open source and I go with CTR and nobody vetos my commit... we have consensus... why do we need to go all Iron Fist and require a vote? We already have established tools: review of commits, vetos on commits, mandatory votes for Category B dependencies... Do we really need *more* processes and procedures to follow? On 2 August 2013 16:51, Paul Benedict pbened...@apache.org wrote: I don't understand the iron hand analogy. I was expressing the use of a vote to allow or disallow critical development outside of Apache. The vote would lead to a consensus, no? On Fri, Aug 2, 2013 at 10:41 AM, Stephen Connolly stephen.alan.conno...@gmail.com wrote: On 2 August 2013 16:32, Paul Benedict pbened...@apache.org wrote: Furthermore, I'd like to see explicit procedural rules on Maven Core and forking. For example, if there's a critical component needing development for Core, and a PMC expresses that such development will be done outside of Apache and then used as a dependency, shouldn't there be a vote on that? Votes should be a tool to confirm consensus... not an iron hand. If the consensus of the developers is to use the dependency which is external to the project, then that is fine. If there is no consensus then the dependency will not be introduced. We already have a policy that adding Category B dependencies to Core requires approval of the PMC, I don't see that there is much value in adding even more to this document... but if you can suggest a patch and people agree with it... -Stephen -- Cheers, Paul -- Cheers, Paul - To unsubscribe, e-mail: users-unsubscr...@maven.apache.org For additional commands, e-mail: users-h...@maven.apache.org
