RE: Plugin Versions in the Super pom

2008-02-09 Thread Brian E. Fox
Yes, I had to walk the poms in the rule to see if the version was specified anywhere. (the model in project always has versions filled in, even if they aren't actually specified in the poms.) The code stops walking up the pom tree when there is no parent specified and it doesn't look in the super p

Re: Plugin Versions in the Super pom

2008-02-09 Thread nicolas de loof
Could the enforcer plugin still warn about missing plugins version if they are set in the super POM ? Nico 2008/2/10, Ralph Goers <[EMAIL PROTECTED]>: > > In my world I require a reproduceable build. Typically, that means a > specific release would have to be built using a specific version of >

RE: Plugin Versions in the Super pom

2008-02-09 Thread Brian E. Fox
>So if this proposal means that each version of Maven hard-wires default >versions of plugins - but that those plugin versions can be overridden >then I definitely agree that that is the correct way to go. This is exactly what I'm proposing. -

Re: Plugin Versions in the Super pom

2008-02-09 Thread Jason van Zyl
On 9-Feb-08, at 9:32 PM, Ralph Goers wrote: In my world I require a reproduceable build. Typically, that means a specific release would have to be built using a specific version of Maven. Any attempt to build it at a later time would need to still use that release. This isn't just becaus

Re: Plugin Versions in the Super pom

2008-02-09 Thread Ralph Goers
In my world I require a reproduceable build. Typically, that means a specific release would have to be built using a specific version of Maven. Any attempt to build it at a later time would need to still use that release. This isn't just because of default versions of plugins but because the

RE: Plugin Versions in the Super pom

2008-02-09 Thread Brian E. Fox
I created a jira for this and will attempt a scan through existing issues to see how many might be related to this. So far we've started to go off on tangential other ideas which is good for 2.1, but I haven't seen any showstopper reason why this could actually hurt anyone. -Original Message

Re: Plugin Versions in the Super pom

2008-02-09 Thread Jason van Zyl
On 9-Feb-08, at 12:31 PM, Benjamin Bentmann wrote: I think the idea of specifying versions in the "super pom" is pointless. Stability for a given release of maven is not particularly useful when many users are using different versions of maven to build something. I think it's common sense tha

Re: Plugin Versions in the Super pom

2008-02-09 Thread Jason van Zyl
On 9-Feb-08, at 12:33 PM, Don Brown wrote: On 2/10/08, Jason van Zyl <[EMAIL PROTECTED]> wrote: You're asking for a far more complicated solutions to be implemented which generally aren't much more helpful. You're also conflating the solution with what people should do and what they should act

Re: Plugin Versions in the Super pom

2008-02-09 Thread Jason van Zyl
On 9-Feb-08, at 11:55 AM, simon wrote: On Sat, 2008-02-09 at 09:04 -0800, Jason van Zyl wrote: On 9-Feb-08, at 8:49 AM, Aaron Metzger wrote: For me, I am completely aware that I want to lock *everything* down (including plugins) to have reproducible builds. So marketing, advertising, pleadi

Re: Plugin Versions in the Super pom

2008-02-09 Thread Benjamin Bentmann
I think the idea of specifying versions in the "super pom" is pointless. Stability for a given release of maven is not particularly useful when many users are using different versions of maven to build something. I think it's common sense that the proposed lock down in the super POM is not the

Re: Plugin Versions in the Super pom

2008-02-09 Thread Don Brown
On 2/10/08, Jason van Zyl <[EMAIL PROTECTED]> wrote: > You're asking for a far more complicated solutions to be implemented > which generally aren't much more helpful. You're also conflating the > solution with what people should do and what they should actually be > doing. Yes, people should use v

Re: Plugin Versions in the Super pom

2008-02-09 Thread nicolas de loof
Could we add some SHORT meta-data in the POM to point to a maven superPOM version ? By default, use the running maven superPOM, but when set, use the expected superPOM. Based on this, we could build with maven 2.0.10 a project designed with maven 2.0.9 superPOM. Nico. 2008/2/9, Brian E. Fox <[E

Re: Plugin Versions in the Super pom

2008-02-09 Thread simon
On Sat, 2008-02-09 at 09:04 -0800, Jason van Zyl wrote: > On 9-Feb-08, at 8:49 AM, Aaron Metzger wrote: > > For me, I am completely aware that I want to lock *everything* down > > (including plugins) to have reproducible builds. So marketing, > > advertising, pleading with us, educating us is

Re: Plugin Versions in the Super pom

2008-02-09 Thread Jason van Zyl
On 9-Feb-08, at 8:49 AM, Aaron Metzger wrote: Brian E. Fox wrote: We advertise the hell out of it and people will discover it as they have a problem that they resolve, can migrate to it as an upgrade process in their company environments and we don't screw someone over with our benevolent

Re: Plugin Versions in the Super pom

2008-02-09 Thread Jason van Zyl
On 9-Feb-08, at 5:53 AM, nicolas de loof wrote: I have to change my vote to -1 : Current maven behavior introduces some issues when plugin version is not set. Many users got errors with this and learned to use version. Having maven super-POM set plugin version will make the build depend

Re: Plugin Versions in the Super pom

2008-02-09 Thread Aaron Metzger
Brian E. Fox wrote: We advertise the hell out of it and people will discover it as they have a problem that they resolve, can migrate to it as an upgrade process in their company environments and we don't screw someone over with our benevolent power. I think the biggest beef people have is that

Re: [ANN] Maven Archetype Plugin 2.0-alpha-1 for Maven 2 Released

2008-02-09 Thread Raphaël Piéroni
The documentation you saw is: - not yet committed - generated from the plugin module the documentation in the parent module is 1 year old. and appart from the descriptor, a bit dated. I commit now the release is done. Regards, Raphaël 2008/2/9, Wendy Smoak <[EMAIL PROTECTED]>: > On Feb 8, 2008

RE: Plugin Versions in the Super pom

2008-02-09 Thread Brian E. Fox
>I have to change my vote to -1 : >Current maven behavior introduces some issues when plugin version is not >set. Many users got errors with this and learned to use version. >Having maven super-POM set plugin version will make the build depend on >maven version used. Compare this change to the

RE: Plugin Versions in the Super pom

2008-02-09 Thread Brian E. Fox
>The reality looks different: http://jira.codehaus.org/browse/MNG-3394 >As a prerequisite for the proposed additions to the super POM, this issue >should be fixed. Yes. I moved it to 2.0.9 as this definitely is related. --Brian ---

RE: Plugin Versions in the Super pom

2008-02-09 Thread Brian E. Fox
>We advertise the hell out of it and people will discover it as they have a >problem that they resolve, can migrate to it as an upgrade process in their >company environments and we don't screw someone over with our benevolent >power. I think the biggest beef people have is that we are unstable b

Re: [Discussion] Continuum 2.0 Roadmap

2008-02-09 Thread Trygve Laugstøl
Rahul Thakur wrote: Overall I think the core of Continuum should be re-though to be more pluggable. In particular a workflow engine should be in the middle of the execution to orchestrate any steps involved with building a project. This is one of the places where people should be able to plug

Re: [Discussion] Continuum 2.0 Roadmap

2008-02-09 Thread Trygve Laugstøl
Rahul Thakur wrote: 1-2)I would like to bring Guice to the mix. I think it is worth investigating for Continuum 2.0 - WDYT? I need a reason to drop the current set of technologies, why is the new set better etc. My motivations behind this were: # leverage Java 5 language and other lib

Re: Hand-written or generated NOTICE.txt file for maven-checkstyle plugin?

2008-02-09 Thread Vincent Siveton
+1 for the generated file. Cheers, Vincent 2008/2/9, Dennis Lundberg <[EMAIL PROTECTED]>: > I'm preparing for a release of maven-checkstyle and just found a > hand-written NOTICE.txt file in the svn repo: > > > https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-checkstyle-plugin/src/main

Hand-written or generated NOTICE.txt file for maven-checkstyle plugin?

2008-02-09 Thread Dennis Lundberg
I'm preparing for a release of maven-checkstyle and just found a hand-written NOTICE.txt file in the svn repo: https://svn.apache.org/repos/asf/maven/plugins/trunk/maven-checkstyle-plugin/src/main/resources/META-INF/NOTICE.txt Should I update this file (copyright year) or just use the one that

Re: Plugin Versions in the Super pom

2008-02-09 Thread Jesse McConnell
+1 in principle. One thought thoughwhat if we were to add the activeProfile element as it exists in the settings.xml into the pom.xml and advertise that users can set something like this in their top level pom.xml: default-maven-plugin-versioning This lets the behavior be optiona

Re: AbstractMavenReport: getProject() and getSiteRenderer()

2008-02-09 Thread Vincent Siveton
Hi Benjamin, AbstractProjectInfoReport uses them. We need to refactor these classes (see MNG-3346) Cheers, Vincent 2008/2/8, Benjamin Bentmann <[EMAIL PROTECTED]>: > Hi, > > why do subclasses of AbstractMavenReport have to implement the abstract > methods getProject() and getSiteRenderer()? I c

Re: [ANN] Maven Archetype Plugin 2.0-alpha-1 for Maven 2 Released

2008-02-09 Thread Wendy Smoak
On Feb 8, 2008 8:40 PM, Raphaël Piéroni <[EMAIL PROTECTED]> wrote: > The Maven team is pleased to announce the release of the Maven > Archetype Plugin, version 2.0-alpha-1 Thanks Raphaël, it's great to see this moving forward. :) I'm concerned about the lack of documentation. The published docs

Re: Plugin Versions in the Super pom

2008-02-09 Thread Benjamin Bentmann
simply discuss the ramifications of defaulting the core plugin versions in the super pom in 2.0 only. +1, might also spare users from learning yet another concept like "plugin-packs". If the super POM locks down all plugins that would be injected by one of the various lifecycle mappings and the

Re: Plugin Versions in the Super pom

2008-02-09 Thread nicolas de loof
I have to change my vote to -1 : Current maven behavior introduces some issues when plugin version is not set. Many users got errors with this and learned to use version. Having maven super-POM set plugin version will make the build depend on maven version used. Simple scenario : I create a pro

Fwd: plugin classpath (regression in maven 2.0.8)

2008-02-09 Thread nicolas de loof
Hello, I used to override code-generator plugin dependencies to set a custom generator version : example : org.codehaus.mojo axistools-maven-plugin 1.2-SNAPSHOT axis axis ${axis.version}

Re: Plugin Versions in the Super pom

2008-02-09 Thread nicolas de loof
+1 I've allready done similar "fix common plugins version" work in my corporate POM, with version set for all org.apache.maven.plugins and many org.codehaus.mojo. Recent release of surefire plugin demonstrates many users suffering from the "get latest" plugin policy, and some builds not beeing re