[VOTE] Release Maven Checkstyle plugin version 2.4

[mihobson]

Hi,

The big new feature in this release is an upgrade to Checkstyle 5.0,
which brings Java 5 compatibility.

We solved 6 issues:
http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127&version=15336

There are still a couple of issues left in JIRA:
http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11127&status=1

Staging repo:
https://repository.apache.org/content/repositories/maven-001/

Staging site:
http://maven.apache.org/plugins/maven-checkstyle-plugin-2.4/
(Wait for sync, or use proxy)

Guide to testing staged releases:
http://maven.apache.org/guides/development/guide-testing-releases.html

Vote open for 72 hours.

[ ] +1
[ ] +0
[ ] -1

Cheers,

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[nicolas de loof-2]

+1

2009/11/12 Mark Hobson <markhobson@...>

> Hi,
>
> The big new feature in this release is an upgrade to Checkstyle 5.0,
> which brings Java 5 compatibility.
>
> We solved 6 issues:
>
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127&version=15336
>
> There are still a couple of issues left in JIRA:
>
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11127&status=1
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-001/
>
> Staging site:
> http://maven.apache.org/plugins/maven-checkstyle-plugin-2.4/
> (Wait for sync, or use proxy)
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[olamy-2]

+1

--
Olivier

2009/11/13 nicolas de loof <nicolas.deloof@...>:

> +1
>
> 2009/11/12 Mark Hobson <markhobson@...>
>
>> Hi,
>>
>> The big new feature in this release is an upgrade to Checkstyle 5.0,
>> which brings Java 5 compatibility.
>>
>> We solved 6 issues:
>>
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127&version=15336
>>
>> There are still a couple of issues left in JIRA:
>>
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11127&status=1
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-001/
>>
>> Staging site:
>> http://maven.apache.org/plugins/maven-checkstyle-plugin-2.4/
>> (Wait for sync, or use proxy)
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Cheers,
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>

--
Olivier

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Hervé BOUTEMY]

+1

Hervé

Le jeudi 12 novembre 2009, Mark Hobson a écrit :

> Hi,
>
> The big new feature in this release is an upgrade to Checkstyle 5.0,
> which brings Java 5 compatibility.
>
> We solved 6 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127&version=15
> 336
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11127&st
> atus=1
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-001/
>
> Staging site:
> http://maven.apache.org/plugins/maven-checkstyle-plugin-2.4/
> (Wait for sync, or use proxy)
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Benjamin Bentmann]

Mark Hobson wrote:

> Staging repo:
> https://repository.apache.org/content/repositories/maven-001/
>
> Staging site:
> http://maven.apache.org/plugins/maven-checkstyle-plugin-2.4/

+1


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Arnaud HERITIER]

+1

Arnaud Héritier
Software Factory Manager
eXo platform - http://www.exoplatform.com
---
http://www.aheritier.net


On Sat, Nov 14, 2009 at 1:32 PM, Benjamin Bentmann <
benjamin.bentmann@...> wrote:

> Mark Hobson wrote:
>
>  Staging repo:
>> https://repository.apache.org/content/repositories/maven-001/
>>
>> Staging site:
>> http://maven.apache.org/plugins/maven-checkstyle-plugin-2.4/
>>
>
> +1
>
>
> Benjamin
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

[Sebastian Annies]

Hi,

we are using a custom lifecycle and bind the maven-source-plugin in
version 2.1 to the verify phase. In the 2.X branch it always worked
perfectly. But now I tried alpha-3 and 4 and it seems that Maven uses
the maven-source-plugin in version 2.0.4 even though I explicitly
require 2.1 ( 2.0.4 does not provide the "jar-no-fork" goal and the
build breaks)!
Has anyone of you experienced similar behavior or is intended to work
that way?

Best Regards,
Sebastian

Have a look at my DefaultLifecycleMapping:

  <lifecycle>
   <id>default</id>
   <phases>
    <generate-sources>net.jangaroo:ext-xml-maven-plugin:${pom.version}:extxml</generate-sources>
    <process-resources>org.apache.maven.plugins:maven-resources-plugin:resources</process-resources>
    <compile>net.jangaroo:jangaroo-maven-plugin:${pom.version}:compile</compile>
    <generate-test-resources>net.jangaroo:jangaroo-maven-plugin:${pom.version}:unpack-jangaroo-test-dependencies</generate-test-resources>
    <process-test-resources>org.apache.maven.plugins:maven-resources-plugin:testResources</process-test-resources>
    <test-compile>net.jangaroo:jangaroo-maven-plugin:${pom.version}:testCompile</test-compile>
    <test>net.jangaroo:jangaroo-maven-plugin:${pom.version}:test</test>
    <package>net.jangaroo:jangaroo-maven-plugin:${pom.version}:package</package>
    <verify>org.apache.maven.plugins:maven-source-plugin:2.1:jar-no-fork</verify>
    <install>org.apache.maven.plugins:maven-install-plugin:install</install>
    <deploy>org.apache.maven.plugins:maven-deploy-plugin:deploy</deploy>
   </phases>
  </lifecycle>
 <lifecycle>

[Benjamin Bentmann]

Sebastian Annies wrote:

> Has anyone of you experienced similar behavior or is intended to work
> that way?

Maybe there's some bad interaction with the default versions in the
super POM, I'll have a closer look.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[vsiveton]

+1

Vincent

2009/11/12 Mark Hobson <markhobson@...>:

> Hi,
>
> The big new feature in this release is an upgrade to Checkstyle 5.0,
> which brings Java 5 compatibility.
>
> We solved 6 issues:
> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127&version=15336
>
> There are still a couple of issues left in JIRA:
> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11127&status=1
>
> Staging repo:
> https://repository.apache.org/content/repositories/maven-001/
>
> Staging site:
> http://maven.apache.org/plugins/maven-checkstyle-plugin-2.4/
> (Wait for sync, or use proxy)
>
> Guide to testing staged releases:
> http://maven.apache.org/guides/development/guide-testing-releases.html
>
> Vote open for 72 hours.
>
> [ ] +1
> [ ] +0
> [ ] -1
>
> Cheers,
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Benjamin Bentmann]

Sebastian Annies wrote:

> we are using a custom lifecycle and bind the maven-source-plugin in
> version 2.1 to the verify phase. In the 2.X branch it always worked
> perfectly. But now I tried alpha-3 and 4 and it seems that Maven uses
> the maven-source-plugin in version 2.0.4

Confirmed and filled as http://jira.codehaus.org/browse/MNG-4453.

This is actually a controversial edge case. For instance, even if one puts

   <build>
     <plugins>
       <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-source-plugin</artifactId>
         <version>2.0.4</version>
       </plugin>
     </plugins>
   </build>

in the POM, Maven 2.x will use the version defined in the lifecycle
mapping, i.e. the lifecycle mapping is dominant. That's not really what
I personally would have expected.

So, not sure right now how we actually want Maven to behave in this case.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[BRIAN FOX-5]

Personally I didn't even know you could put a version into the
lifecycle, I've never seen that done.

Second, I always subscribe to the theory that "closest" wins. In the
inheritance case, it means things in my pom override my parent pom,
which overrides the grandparent etc. I think in this case, the pom is
"closer" than the lifecycle and therefore it should win as is
happening in the 3.x case. In otherwords, if I use a lifecycle that
defines a version but need to tweak the version how would I do it? The
pom is my only vechicle for overriding it.

On Tue, Nov 17, 2009 at 6:18 PM, Benjamin Bentmann
<benjamin.bentmann@...> wrote:

> Sebastian Annies wrote:
>
>> we are using a custom lifecycle and bind the maven-source-plugin in
>> version 2.1 to the verify phase. In the 2.X branch it always worked
>> perfectly. But now I tried alpha-3 and 4 and it seems that Maven uses
>> the maven-source-plugin in version 2.0.4
>
> Confirmed and filled as http://jira.codehaus.org/browse/MNG-4453.
>
> This is actually a controversial edge case. For instance, even if one puts
>
>  <build>
>    <plugins>
>      <plugin>
>        <groupId>org.apache.maven.plugins</groupId>
>        <artifactId>maven-source-plugin</artifactId>
>        <version>2.0.4</version>
>      </plugin>
>    </plugins>
>  </build>
>
> in the POM, Maven 2.x will use the version defined in the lifecycle mapping,
> i.e. the lifecycle mapping is dominant. That's not really what I personally
> would have expected.
>
> So, not sure right now how we actually want Maven to behave in this case.
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Benjamin Bentmann]

Brian Fox wrote:

> Second, I always subscribe to the theory that "closest" wins.
> [...] I think in this case, the pom is
> "closer" than the lifecycle and therefore it should win as is
> happening in the 3.x case.

I agree, it's simply a matter of giving the build engineer control over
his build.

Still, the particular use case sketched by Sebastian or at least part of
looks valid to me. Imagine a minimal POM (i.e. without parents) that
uses his custom lifecycle mapping. Because we define some plugin
versions in the super POM's plugin management, this build will

a) observe some plugin versions from the lifecycle mapping being
respected but others not (-> confusion)

b) require additional XML in form of plugin management to eventually
enforce the desired plugin version to make the lifecycle mapping work as
originally designed (-> overhead)

So for this case, the super POM looks more like an obstacle to me.

But AFAIR, we introduced plugin versions in the super POM for just one
reason, namely to provide versions for the plugins used by the built-in
lifecycle mappings. So how about if we removed the entire plugin
management from the super POM and instead specified the plugin versions
directly in the lifecycle mappings?

Apparently, this change would make custom lifecycle mappings that don't
specify plugin versions subject to automatic plugin version resolution
as in Maven 2.0.8- unless the consuming POM (or its parents) locked the
version down. On the hand, Maven 3 will report this situation as a
prominent warning and we preach locking down plugin versions for some
time now.

WDYT?


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Sebastian Annies]

 From a user's Point of View it seems only logical to me that the  
lifecycle defines which versions of the Plugins should Be used. The  
super pom is no help

Von meinem iPod gesendet

Am 18.11.2009 um 11:58 schrieb "Benjamin Bentmann" <benjamin.bentmann@...
 >:

> Brian Fox wrote:
>
>> Second, I always subscribe to the theory that "closest" wins.
>> [...] I think in this case, the pom is
>> "closer" than the lifecycle and therefore it should win as is
>> happening in the 3.x case.
>
> I agree, it's simply a matter of giving the build engineer control  
> over his build.
>
> Still, the particular use case sketched by Sebastian or at least  
> part of looks valid to me. Imagine a minimal POM (i.e. without  
> parents) that uses his custom lifecycle mapping. Because we define  
> some plugin versions in the super POM's plugin management, this  
> build will
>
> a) observe some plugin versions from the lifecycle mapping being  
> respected but others not (-> confusion)
>
> b) require additional XML in form of plugin management to eventually  
> enforce the desired plugin version to make the lifecycle mapping  
> work as originally designed (-> overhead)
>
> So for this case, the super POM looks more like an obstacle to me.
>
> But AFAIR, we introduced plugin versions in the super POM for just  
> one reason, namely to provide versions for the plugins used by the  
> built-in lifecycle mappings. So how about if we removed the entire  
> plugin management from the super POM and instead specified the  
> plugin versions directly in the lifecycle mappings?
>
> Apparently, this change would make custom lifecycle mappings that  
> don't specify plugin versions subject to automatic plugin version  
> resolution as in Maven 2.0.8- unless the consuming POM (or its  
> parents) locked the version down. On the hand, Maven 3 will report  
> this situation as a prominent warning and we preach locking down  
> plugin versions for some time now.
>
> WDYT?
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[mihobson]

Hi,

The vote has passed with the following result :

+1 (binding): Arnaud HERITIER, Benjamin Bentmann, Hervé BOUTEMY,
Olivier Lamy, Vincent Siveton
+1 (non binding): nicolas de loof

I will promote the artifacts to the central repo.

Mark

2009/11/17 Vincent Siveton <vsiveton@...>:

> +1
>
> Vincent
>
> 2009/11/12 Mark Hobson <markhobson@...>:
>> Hi,
>>
>> The big new feature in this release is an upgrade to Checkstyle 5.0,
>> which brings Java 5 compatibility.
>>
>> We solved 6 issues:
>> http://jira.codehaus.org/secure/ReleaseNote.jspa?projectId=11127&version=15336
>>
>> There are still a couple of issues left in JIRA:
>> http://jira.codehaus.org/secure/IssueNavigator.jspa?reset=true&pid=11127&status=1
>>
>> Staging repo:
>> https://repository.apache.org/content/repositories/maven-001/
>>
>> Staging site:
>> http://maven.apache.org/plugins/maven-checkstyle-plugin-2.4/
>> (Wait for sync, or use proxy)
>>
>> Guide to testing staged releases:
>> http://maven.apache.org/guides/development/guide-testing-releases.html
>>
>> Vote open for 72 hours.
>>
>> [ ] +1
>> [ ] +0
>> [ ] -1
>>
>> Cheers,
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@...
>> For additional commands, e-mail: dev-help@...
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@...
> For additional commands, e-mail: dev-help@...
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[BRIAN FOX-5]

> Apparently, this change would make custom lifecycle mappings that don't
> specify plugin versions subject to automatic plugin version resolution as in
> Maven 2.0.8- unless the consuming POM (or its parents) locked the version
> down. On the hand, Maven 3 will report this situation as a prominent warning
> and we preach locking down plugin versions for some time now.


At first blush I think this is in the right direction, but I have a
few thoughts that I want to throw out:

1) we included some plugins that are commonly used but aren't in a
lifecycle such as the dependency and enforcer plugins.

2) what are the impacts to the plugin when it's run in multiple
lifecycles, or if the user binds it to a phase of some other
lifecycle? Would this cause the version to vary in unpredictable ways?

3) what is the impact to direct cli invocation now?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Benjamin Bentmann]

Brian Fox wrote:

> 1) we included some plugins that are commonly used but aren't in a
> lifecycle such as the dependency and enforcer plugins.

I know, if those are declared in the POM they have to have/inherit a
version or Maven 3.0 will output a warning.

In other words, what we consider "commonly used" would no longer get
special treatment. A plugin is either used by a lifecycle mapping or not.

> 2) what are the impacts to the plugin when it's run in multiple
> lifecycles, or if the user binds it to a phase of some other
> lifecycle? Would this cause the version to vary in unpredictable ways?

Good questions, let's look closer at the edge cases:

A reminder first: For a given project, Maven 3 will use exactly one
version of a plugin.

For a single lifecycle mapping that defines the same plugin multiple
times with different versions, the first version would win.

For multiple lifecycles, we would need to define some canonical order of
the lifecycles (e.g. alphabetical by id, "clean", "default", "site") to
reliably solve version conflicts from potentially different lifecycle
mappings for the different lifecycles. Right now, the lifecycle executor
inspects the lifecycles in injected/arbitrary order.

The POM would be dominant over the lifecycle mapping. So any <plugin>
declarations the users puts into it will override the version given in
the lifecycle mapping, regardless from what lifecycle.

Another interesting case is the (deprecated) release profile. Given that
neither the Javadoc nor the Source Plugin are part of the lifecycle
mapping, they would no longer have default versions and Maven 3 will
output warnings unless a child POM locks them down.

> 3) what is the impact to direct cli invocation now?

The resolution process for a missing plugin version is

1. project/build/plugins
2. project/build/pluginManagement/plugins
3. RELEASE/LATEST from repository

So, if the plugin in question is declared in the POM (or any parent),
the version from the POM will be used. Otherwise it's back to the auto mode.

For instance, if someone invokes "mvn compile:compile" on a JAR project,
the same version will be used as for "mvn compile", because the
lifecycle mappings will be reflected in the effective POM and as such
provide the version for the maven-compiler-plugin.

If someone invokes "mvn install:install-file" on a POM-less directory,
the plugin version would be resolved from the repo metadata instead of
the super POM defaults.

To sum up, there will be cases where we loose default versions compared
to 2.x but IMHO those are acceptable and weigh less than the problem
with versioned lifecycle mappings we're trying to solve. As a side note,
I like the idea to eventually see the super POM being free of any plugins.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[BRIAN FOX-5]

>> 2) what are the impacts to the plugin when it's run in multiple
>> lifecycles, or if the user binds it to a phase of some other
>> lifecycle? Would this cause the version to vary in unpredictable ways?
>
> Good questions, let's look closer at the edge cases:
>

I guess what I had in mind was given a single reactor build:
A : Jar
B: War but binds jar to a phase.

Will B always get the same version of the jar plugin as A?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Benjamin Bentmann]

Brian Fox wrote:

> I guess what I had in mind was given a single reactor build:
> A : Jar
> B: War but binds jar to a phase.
>
> Will B always get the same version of the jar plugin as A?

No, the projects are handled independently regarding their build plugins.

For instance, if B doesn't lock down the version of the JAR plugin it
will encounter auto resolution, while A could use a default version from
the lifecycle mapping for "jar" packaging.

In other words, running "mvn install" on B or A alone is equivalent to
running "mvn install" on the reactor build. Ignoring dependency
resolution, we made some efforts in Maven 3 to ensure projects build the
same regardless whether they run in a reactor or in isolation.

The lifecycle mapping gets merged into the effective POM for a project
and the lifecycle executor respects the versions given for a particular
project, no more MNG-1323.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[BRIAN FOX-5]

On Thu, Nov 19, 2009 at 1:24 PM, Benjamin Bentmann
<benjamin.bentmann@...> wrote:
> Brian Fox wrote:
>
>> I guess what I had in mind was given a single reactor build:
>> A : Jar
>> B: War but binds jar to a phase.
>>
>> Will B always get the same version of the jar plugin as A?
>
> No, the projects are handled independently regarding their build plugins.

That's what I expected. Not sure how I feel about that, it certainly
would be confusing when one module does one thing and another does it
differently. Admittedly an edge case completely covered by locking
down your versions anyway.

What is the behavior in an embedded env like M2e? Since it's not going
to execute the full lifecycle, it probably needs to have the same
logic regardless to look at the lifecycle and pick the right version
of a plugin it does run.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...

[Benjamin Bentmann]

Brian Fox wrote:

> What is the behavior in an embedded env like M2e? Since it's not going
> to execute the full lifecycle, it probably needs to have the same
> logic regardless to look at the lifecycle and pick the right version
> of a plugin it does run.

Not sure I understand that question. Embedders of M3 would use M3 APIs
and components so whatever we realize in M3 core will be available for
the embedder as well.

For instance, the lifecycle mappings get merged into the effective POM.
So whatever uses the ProjectBuilder and asks it to process plugins will
get a model that reflects inheritance, plugin management and lifecycle
mappings. Hand the resulting MavenProject to the lifecycle executor and
you get back the execution plan, with all plugin versions resolved.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@...
For additional commands, e-mail: dev-help@...