On 28 Mar 07, at 7:46 PM 28 Mar 07, Brett Porter wrote:
Hi,
I didn't want to pin the assembly plugin vote to this, but it
seemed like a good opportunity to bring this up.
I'd like to propose we split the stable repository from the
unstable repository (which would be where alphas, betas and rcs get
deployed), and make this a documented best practice.
I don't see the value in this at all. A release is already from
distinguished, and to add another layer of meaning to this adds more
complexity and will be a source of great confusion.
This would not be a concept change in Maven (at least, yet - it
could be something to consider in the versioning in future): it's
simply two types of release repositories. The stable one would be
included in Maven by default, the unstable/pre-release one would
not. You'd have to add the repository to your project.
-1
It's already complicated enough and I think we should, in fact, go
the other way and put a default SNAPSHOT repository in the process by
default so that thousands of people don't have diddle POMs all the time.
The anti pattern we have now when switching to a snapshot is having
to add the snapshot repository definition. When you move to a release
if you wanted to be accurate you would remove the snapshot repository
entry. If you're lazy, like most people, then you just leave the
definition in there anyway. So some of the time the list of
repositories is accurate, sometimes not. We should just put the
snapshot repository in by default and find better ways of
distinguishing the use of snapshots or various levels of quality with
metadata. We're already making this harder for users and adding
another layer to this would be crazy. People would have to go look in
different repositories and have to define yet another repository
entry, that's just so inconvenient.
I would suggest this for future additions to central, but leave
anything currently there in place for backwards compat.
Having separate repositories is fine for manageability but having to
diddle POMs all the time is very annoying especially for day-to-day
use. I think anyone experiencing the pain of this would not want
this. Case in point is building trunk and building and deploying a
snapshot locally and deploying it and then a build not working
because I didn't put in a snapshot repository. It's an asymmetry that
really makes no sense and is a great source of irritation and often
leads to builds that don't work out of the box because of this
asymmetry.
I think this is a good all round concept, but there is a particular
practical problem that we should do this for: unpinned plugin
versions. In the specific example of the assembly plugin - if you
don't request a version (ie, use latest release), or you said
[2.1,), then you'll get the 2.2-beta-1 release which is presumably
less stable than 2.1. The same rationalisation would apply to
ranges used in any dependency, but thats the biggest use case I can
think of that affects people today. It would allow us to do more
regular test releases of the plugins.
Thoughts?
I think this is a not a good idea. We should make this easier for
users not harder. And for plugins in 2.1 we should make people
specify versions and again restore symmetry in the use
pluginManagement like dependencyManagement as well as turning off any
automatic updates. Many things were not working as a result of
magically finding the last release, the plugin registry being the
biggest culprit but users can specify versions for plugins as they
very accustom to this and the same management techniques can be used.
Anyone who wants a reliable build is doing this already.
I'm far more in favor of hosting a default snapshot repository on
central and forcing plugin versions in 2.1. This creates far more
stability and puts the onus on us to make finding that version for
first time use easy. Not specifying a version for a plugin is not
predictable as clearly shown with the last release of the surefire.
If I had to specify surefire 2.2 then trunk would not have broken, or
the 2.0.x branch. I think we should be striving for ease of use and
stability.
So in summary, more default repositories definitions not more types
of repositories. Put a default snapshot repository on central, find
some reasonable eviction policy and make day-to-day use easier. Also
make the specification of the plugin version to bring that into
common pattern that is the same for dependencies.
Jason.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
