You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Simon Kitching <sk...@apache.org> on 2007/12/31 13:21:05 UTC
Re: Remove auto-resolution of plugin versions from Maven 2.1
Hi All,
John Casey wrote:
>
> Hi everyone,
>
> I'd like to make sure we're all on the same page with the plugin
> auto-version resolution stuff that we've been discussing lately (on the
> assembly-plugin vote thread, for one thing). I think it's clear that we
> cannot continue to allow Maven to resolve RELEASE or LATEST meta-versions
> for plugins any more. I'd actually argue that this is bad practice for ANY
> artifact that is to be resolved, including site skins, etc. since it kills
> our ability to deprecate features.
>
I've read through this complete thread and not seen any proposed solution
that I like.
How about providing a way to
(a) dump the current dependencies to an external file, and
(b) for any build, optionally specify an external "dependency versions" file
to use when resolving dependencies.
So, the POM still defines "logical" dependencies, eg "version 2.1 or
greater".
However when a release is about to be made, the release manager:
(1) runs a goal to generate the explicit dependencies file". This file
contains a list of all the
dependencies, and the EXACT version that is currently resolved, eg not "2.1
or greater", but "2.2-beta-1" for example.
(2) checks this explicit dependencies file in to the VCS
(3) builds the release candidate using the explicit dependencies file. Maven
dependency resolution then *always* uses the dependencies in the input file,
rather than its usual "best fit" algorithm.
This seems to allow the POM to still remain abstract about dependencies (not
being locked down to a particular version) while allowing repeatable builds.
Building without using the checked-in dependencies file does normal
dependency resolution. However people can also choose to invoke maven with
the checked-in explicit-dependencies file to create a repeatable build.
The separate dependencies file seems useful as documentation in its own
right, rather like the "dependencies report" that can be generated for
websites.
Regards,
Simon
--
View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tp9943861s177p14557013.html
Sent from the Maven Developers mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Remove auto-resolution of plugin versions from Maven 2.1
Posted by Jason van Zyl <ja...@maven.org>.
On 14-Jan-08, at 9:18 AM, Mark Hobson wrote:
> On 03/01/2008, Brett Porter <br...@apache.org> wrote:
>> I said intended, because from memory I wasn't sure if it was still
>> commented out :)
>
> I implemented release POMs in maven-release-plugin 2.0-beta-6, see:
>
> http://jira.codehaus.org/browse/MRELEASE-177
>
I'll look but I assume this is using the notation that actually locks
down the versions, which was not done previously thereby making the
POM produced effectively useless for reproducibility.
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
You are never dedicated to something you have complete confidence in.
No one is fanatically shouting that the sun is going to rise tomorrow.
They know it is going to rise tomorrow. When people are fanatically
dedicated to political or religious faiths or any other kind of
dogmas or goals, it's always because these dogmas or
goals are in doubt.
-- Robert Pirzig, Zen and the Art of Motorcycle Maintenance
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Remove auto-resolution of plugin versions from Maven 2.1
Posted by Mark Hobson <ma...@gmail.com>.
On 03/01/2008, Brett Porter <br...@apache.org> wrote:
> I said intended, because from memory I wasn't sure if it was still
> commented out :)
I implemented release POMs in maven-release-plugin 2.0-beta-6, see:
http://jira.codehaus.org/browse/MRELEASE-177
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Remove auto-resolution of plugin versions from Maven 2.1
Posted by Brett Porter <br...@apache.org>.
I said intended, because from memory I wasn't sure if it was still
commented out :)
The problem with the use of this POM for release:perform is that it
will be deployed into the repository - and that's not what you want.
You then get the resolved dependencies instead of the declared ones,
which causes anything that uses it as a dependency to have a more
restrictive situation. It really needs the adjustments to the artifact
system, and the POM, that let you separate the declaration from the
resolved graph to be useful.
Cheers,
Brett
On 03/01/2008, at 8:10 AM, Matt Ryall wrote:
> On Jan 1, 2008 1:28 AM, Brett Porter <br...@apache.org> wrote:
>
>> FWIW, This is precisely the functionality that the
>> "generateReleasePoms" flag of the release plugin was intended to
>> provide.
>>
>
> "Intended to provide"? Does it actually provide it?
>
> The documentation for this flag seems a bit inconsistent. It's
> listed as a
> property for 'release:prepare' at [1], but the example uses
> 'release:perform' [2]. Will the perform always use the release-
> pom.xml if it
> exists?
>
> Cheers,
> Matt
>
> [1] http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html
> [2]
> http://maven.apache.org/plugins/maven-release-plugin/examples/generate-release-poms.html
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Remove auto-resolution of plugin versions from Maven 2.1
Posted by Matt Ryall <ma...@mattryall.net>.
On Jan 1, 2008 1:28 AM, Brett Porter <br...@apache.org> wrote:
> FWIW, This is precisely the functionality that the
> "generateReleasePoms" flag of the release plugin was intended to
> provide.
>
"Intended to provide"? Does it actually provide it?
The documentation for this flag seems a bit inconsistent. It's listed as a
property for 'release:prepare' at [1], but the example uses
'release:perform' [2]. Will the perform always use the release-pom.xml if it
exists?
Cheers,
Matt
[1] http://maven.apache.org/plugins/maven-release-plugin/prepare-mojo.html
[2]
http://maven.apache.org/plugins/maven-release-plugin/examples/generate-release-poms.html
Re: Remove auto-resolution of plugin versions from Maven 2.1
Posted by Brett Porter <br...@apache.org>.
FWIW, This is precisely the functionality that the
"generateReleasePoms" flag of the release plugin was intended to
provide.
(Happy New Year from Aus. everyone :)
Cheers,
Brett
On 31/12/2007, at 11:21 PM, Simon Kitching wrote:
>
> Hi All,
>
>
> John Casey wrote:
>>
>> Hi everyone,
>>
>> I'd like to make sure we're all on the same page with the plugin
>> auto-version resolution stuff that we've been discussing lately (on
>> the
>> assembly-plugin vote thread, for one thing). I think it's clear
>> that we
>> cannot continue to allow Maven to resolve RELEASE or LATEST meta-
>> versions
>> for plugins any more. I'd actually argue that this is bad practice
>> for ANY
>> artifact that is to be resolved, including site skins, etc. since
>> it kills
>> our ability to deprecate features.
>>
>
> I've read through this complete thread and not seen any proposed
> solution
> that I like.
>
> How about providing a way to
> (a) dump the current dependencies to an external file, and
> (b) for any build, optionally specify an external "dependency
> versions" file
> to use when resolving dependencies.
>
> So, the POM still defines "logical" dependencies, eg "version 2.1 or
> greater".
>
> However when a release is about to be made, the release manager:
>
> (1) runs a goal to generate the explicit dependencies file". This file
> contains a list of all the
> dependencies, and the EXACT version that is currently resolved, eg
> not "2.1
> or greater", but "2.2-beta-1" for example.
>
> (2) checks this explicit dependencies file in to the VCS
>
> (3) builds the release candidate using the explicit dependencies
> file. Maven
> dependency resolution then *always* uses the dependencies in the
> input file,
> rather than its usual "best fit" algorithm.
>
> This seems to allow the POM to still remain abstract about
> dependencies (not
> being locked down to a particular version) while allowing repeatable
> builds.
> Building without using the checked-in dependencies file does normal
> dependency resolution. However people can also choose to invoke
> maven with
> the checked-in explicit-dependencies file to create a repeatable
> build.
>
> The separate dependencies file seems useful as documentation in its
> own
> right, rather like the "dependencies report" that can be generated for
> websites.
>
> Regards,
>
> Simon
> --
> View this message in context: http://www.nabble.com/Remove-auto-resolution-of-plugin-versions-from-Maven-2.1-tp9943861s177p14557013.html
> Sent from the Maven Developers mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org