You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by "Moser, Christian" <cm...@metrohm.com> on 2011/07/13 13:29:03 UTC

Locking down default plugin versions

I start a release build with following cmd:

 

Mvn -Darguments="-DskipTests=true -Denforcer.skip=true
-Dmaven.javadoc.skip=${skipJavadoc}" -Dtag=${tag}
-Dmaven.javadoc.skip=${skipJavadoc} -Dgoals=deploy release:perform

 

With maven-release-plugin:2.1:perform, maven 3.0.1 will print out:

 

[exec] [INFO] --- maven-release-plugin:2.1:perform (default-cli) @
depmgmt-basesys ---

     [exec] [INFO] Checking out the project to perform the release ...

     [exec] [INFO] Executing: cmd.exe /X /C "svn --non-interactive
checkout
svn://svn-repo.metrohm.local/pcsoft1/MNet-tags/magic-BaseSys/2.17.0
D:\build\MNet\root\MagIC\BaseSys\trunk\target\checkout"

     [exec] [INFO] Working directory:
D:\build\MNet\root\MagIC\BaseSys\trunk\target

     [exec] [INFO] Executing goals 'deploy'...

     [exec] [WARNING] Maven will be executed in interactive mode, but no
input stream has been configured for this MavenInvoker instance.

     [exec] [INFO] [INFO] Scanning for projects...

     [exec] [INFO] [WARNING] 

     [exec] [INFO] [WARNING] Some problems were encountered while
building the effective model for
mnet-magic:comp-appconfiguration:jar:2.17.0

     [exec] [INFO] [WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-javadoc-plugin is missing.

     [exec] [INFO] [WARNING] 'build.plugins.plugin.version' for
org.apache.maven.plugins:maven-deploy-plugin is missing.

     [exec] [INFO] [WARNING]

 

I'm skipping javadoc, do you know  why javadoc-plugin is needed?

Furthermore, I wonder if it's even a good idea to lock down
maven-deploy-plugin because it's already specified in maven super pom.

 

Those warnings are only shown while performing a release.

 

Thx, Chris


AW: AW: Locking down default plugin versions

Posted by "Moser, Christian" <cm...@metrohm.com>.
Thx for your respones.

I was aware of the best practive approach to lock down plugin versions, which I already did for several non default lifecycle plugins like enforcer, antrun, release, scm, resources, antlr3, dependency etc.. But I didn't for deploy plugin, because I thought "default maven plugins" are specified by the currently used M3 version, which is tagged with my builds and because M3 didn't told me so, there were only warnings in combination with the release plugin.

Now, I going to lock down every plugin which is used for the build.

Greez Chris

-----Ursprüngliche Nachricht-----
Von: Barrie Treloar [mailto:baerrach@gmail.com] 
Gesendet: Donnerstag, 14. Juli 2011 01:35
An: Maven Users List; joerg.schaible@gmx.de
Betreff: Re: AW: Locking down default plugin versions

On Thu, Jul 14, 2011 at 1:27 AM, Jörg Schaible <jo...@gmx.de> wrote:
> Moser, Christian wrote:
>
>>> Each plugin decides if it will allow "skip", and so the plugin still
>>> needs to get loaded to decide whether to skip.
>>
>> This makes sense. Will add javadoc-plugin.
>>
>>> What do you mean by "maven super pom"?
>>
>> Maybe "maven super pom" was confusing sorry for that.
>> I meant the "place" where maven specified, which version for the "default"
>> plugins is used. For example, M3 will show a warning if you use, for
>> example versions-plugin without declaring a version in the pom. But I
>> guess it's possible to run a build without declaring deploy-plugin and not
>> to receive a warning. So, somewhere the deploy-plugin is declared for the
>> current Maven version, isn't it?

I think the default version is LATEST, which means there is no locking
down of versions

> But this is the whole point of locking them down: Different Maven versions
> define also different plugin versions. How should your build be repeatable
> then?

As Jörg points out, that means your build is not repeatable.
In a years time, if someone checks out your tagged source and run
maven it may work, but chances are there are new features in the build
that may cause gotchas.
To avoid these its best practice to lock down versions of plugins in
your corporate pom.
I see you've already got enforcer, so over time as you run through all
the lifecycles you will gradually fill in the blanks for any
unspecified plugins into your corporate pom.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: AW: Locking down default plugin versions

Posted by Barrie Treloar <ba...@gmail.com>.
On Thu, Jul 14, 2011 at 1:27 AM, Jörg Schaible <jo...@gmx.de> wrote:
> Moser, Christian wrote:
>
>>> Each plugin decides if it will allow "skip", and so the plugin still
>>> needs to get loaded to decide whether to skip.
>>
>> This makes sense. Will add javadoc-plugin.
>>
>>> What do you mean by "maven super pom"?
>>
>> Maybe "maven super pom" was confusing sorry for that.
>> I meant the "place" where maven specified, which version for the "default"
>> plugins is used. For example, M3 will show a warning if you use, for
>> example versions-plugin without declaring a version in the pom. But I
>> guess it's possible to run a build without declaring deploy-plugin and not
>> to receive a warning. So, somewhere the deploy-plugin is declared for the
>> current Maven version, isn't it?

I think the default version is LATEST, which means there is no locking
down of versions

> But this is the whole point of locking them down: Different Maven versions
> define also different plugin versions. How should your build be repeatable
> then?

As Jörg points out, that means your build is not repeatable.
In a years time, if someone checks out your tagged source and run
maven it may work, but chances are there are new features in the build
that may cause gotchas.
To avoid these its best practice to lock down versions of plugins in
your corporate pom.
I see you've already got enforcer, so over time as you run through all
the lifecycles you will gradually fill in the blanks for any
unspecified plugins into your corporate pom.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: AW: Locking down default plugin versions

Posted by Jörg Schaible <jo...@gmx.de>.
Moser, Christian wrote:

>> Each plugin decides if it will allow "skip", and so the plugin still
>> needs to get loaded to decide whether to skip.
> 
> This makes sense. Will add javadoc-plugin.
> 
>> What do you mean by "maven super pom"?
> 
> Maybe "maven super pom" was confusing sorry for that.
> I meant the "place" where maven specified, which version for the "default"
> plugins is used. For example, M3 will show a warning if you use, for
> example versions-plugin without declaring a version in the pom. But I
> guess it's possible to run a build without declaring deploy-plugin and not
> to receive a warning. So, somewhere the deploy-plugin is declared for the
> current Maven version, isn't it?

But this is the whole point of locking them down: Different Maven versions 
define also different plugin versions. How should your build be repeatable 
then?

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


AW: Locking down default plugin versions

Posted by "Moser, Christian" <cm...@metrohm.com>.
> Each plugin decides if it will allow "skip", and so the plugin still
> needs to get loaded to decide whether to skip.

This makes sense. Will add javadoc-plugin.

> What do you mean by "maven super pom"?

Maybe "maven super pom" was confusing sorry for that.
I meant the "place" where maven specified, which version for the "default" plugins is used.
For example, M3 will show a warning if you use, for example versions-plugin without declaring a version in the pom. But I guess it's possible to run a build without declaring deploy-plugin and not to receive a warning.
So, somewhere the deploy-plugin is declared for the current Maven version, isn't it?

I maintance a corporate pom and wonder why this error message only appear while using the maven-release-plugin:2.1:perform

Chris

-----Ursprüngliche Nachricht-----
Von: Barrie Treloar [mailto:baerrach@gmail.com] 
Gesendet: Mittwoch, 13. Juli 2011 14:32
An: Maven Users List
Betreff: Re: Locking down default plugin versions

On Wed, Jul 13, 2011 at 8:59 PM, Moser, Christian <cm...@metrohm.com> wrote:
> I'm skipping javadoc, do you know  why javadoc-plugin is needed?

Skipping a plugin isn't a built-in maven feature.
Each plugin decides if it will allow "skip", and so the plugin still
needs to get loaded to decide whether to skip.
So its still a good practice to lock down the version.

> Furthermore, I wonder if it's even a good idea to lock down
> maven-deploy-plugin because it's already specified in maven super pom.

What do you mean by "maven super pom"?
Since maven is telling you its not locked down I suspect that you
aren't using the maven super pom.
Which leads me to the next question, why would you want to?
Unless you are an apache project using the maven super pom is probably
not what you want.
You want to define these things in a corporate super pom instead.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Locking down default plugin versions

Posted by Barrie Treloar <ba...@gmail.com>.
On Wed, Jul 13, 2011 at 8:59 PM, Moser, Christian <cm...@metrohm.com> wrote:
> I'm skipping javadoc, do you know  why javadoc-plugin is needed?

Skipping a plugin isn't a built-in maven feature.
Each plugin decides if it will allow "skip", and so the plugin still
needs to get loaded to decide whether to skip.
So its still a good practice to lock down the version.

> Furthermore, I wonder if it's even a good idea to lock down
> maven-deploy-plugin because it's already specified in maven super pom.

What do you mean by "maven super pom"?
Since maven is telling you its not locked down I suspect that you
aren't using the maven super pom.
Which leads me to the next question, why would you want to?
Unless you are an apache project using the maven super pom is probably
not what you want.
You want to define these things in a corporate super pom instead.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org