You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2007/03/29 01:46:27 UTC
[discuss] Splitting the stable and unstable repositories
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.
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.
I would suggest this for future additions to central, but leave
anything currently there in place for backwards compat.
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?
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [discuss] Splitting the stable and unstable repositories
Posted by Andrew Williams <an...@handyande.co.uk>.
Not entirely sure I agree with this point. Another level of
complexity to get round this issue?
surely if folk have any problems they can use dependencyManagement
and pluginManagement to solve
the same issue?
I know plenty of folk who barely know why to separate snapshot from
release repositories, I think adding another split will just raise
the bar of easy adoption...
Andy
On 29 Mar 2007, at 00:46, 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.
>
> 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.
>
> I would suggest this for future additions to central, but leave
> anything currently there in place for backwards compat.
>
> 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?
>
> - Brett
>
> ---------------------------------------------------------------------
> 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
Re: [discuss] Splitting the stable and unstable repositories
Posted by Jason van Zyl <ja...@maven.org>.
On 30 Mar 07, at 10:41 AM 30 Mar 07, Brett Porter wrote:
>
> On 31/03/2007, at 12:09 AM, Jason van Zyl wrote:
>
>>> 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
>
> Ok - having reflected on this, I still believe in the concept but
> agree that it won't be practical without first making it easier to
> declare your repositories without all the extra work that is
> required now.
>
>>
>> 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.
>
> No real objections here.
>
>> So in summary, more default repositories definitions not more
>> types of repositories.
>
> I'm not sure that's a fair summary. Specifying your repositories
> globally needs to be simpler, trying to shove everything
> (especially snapshots) through central is impractical.
In a separate repository that's pulled in by all the syncing
partners? Why is that impractical? It would make it an order of
magnitude easier for users. Again the onus is on us. But syncing the
snapshot repos is no harder then syncing the production repositories
and the new central repo machine has very large disks.
>
>> 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.
>
> +1 on both easier day to day use and locking down versions.
>
> - Brett
>
> ---------------------------------------------------------------------
> 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
Re: [discuss] Splitting the stable and unstable repositories
Posted by Brett Porter <br...@apache.org>.
On 31/03/2007, at 12:09 AM, Jason van Zyl wrote:
>> 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
Ok - having reflected on this, I still believe in the concept but
agree that it won't be practical without first making it easier to
declare your repositories without all the extra work that is required
now.
>
> 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.
No real objections here.
> So in summary, more default repositories definitions not more types
> of repositories.
I'm not sure that's a fair summary. Specifying your repositories
globally needs to be simpler, trying to shove everything (especially
snapshots) through central is impractical.
> 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.
+1 on both easier day to day use and locking down versions.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [discuss] Splitting the stable and unstable repositories
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
<snip a whole bunch>
Jason said:
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.
---
I agree 100%. Anyone concerned about reproducibility would never allow
the plugins to be unversioned in their builds. For my corp builds, it's
as if this feature never existed...everything is in pluginMgt. I think
if we are to encourage best practices, requiring a version somewhere,
either in the plugin definition or pluginManagement is the right thing
to do.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [discuss] Splitting the stable and unstable repositories
Posted by Jason van Zyl <ja...@maven.org>.
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: 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
RE: [discuss] Splitting the stable and unstable repositories
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
>Good point, but shouldn't that stable functionality be in the
>previous release, which folks should still be using in production
>until they need to upgrade?
In this case, yes because the stable goals have not changed at all (and
this is where pluginMgt comes in). However if the repos are split, the
fact that the plugin as a whole is alpha means it's not easily
accessible to someone without adding a pluginRepo to their pom/settings.
Meaning that someone can't just type dependency:analyze until it's
finally released as 2.0.
> You can actually do this (yet another not well documented thing):
>mvn
org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-4:analyze
Good to know..this is grotesque, but still easier than changing my
"super" pom, redeploying and updating tlp poms etc just to try something
out ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: [discuss] Splitting the stable and unstable repositories
Posted by Brett Porter <br...@apache.org>.
On 29/03/2007, at 1:03 PM, Brian E. Fox wrote:
> Brett,
> I can see some logic to this as it's just another shade of grey
> between
> the current snapshot repo and central. It does however feel a little
> like a hack to work around some version ranging issues. I think
> massembly is a good example of where this is needed, but perhaps
> mdep is
> a case where it's not. This is still in "alpha" because there are more
> goals planned to be added. While the plugin overall is alpha, some of
> the original goals (copy/unpack, etc) are quite mature and very
> stable.
> If we did this, it would raise the bar a little higher for people
> to get
> useful functionality.
Good point, but shouldn't that stable functionality be in the
previous release, which folks should still be using in production
until they need to upgrade?
<snip stuff I agree with>
>
> The only thing that is slightly annoying is when you have plugins with
> goals that are both meant to be bound and some for the CLI. When
> you put
> a plugin in to pluginManagement, this applies even to the CLI
> versions.
> I'm not sure if/how we could make this better but here's the use
> case: I
> use mdep to unpack and copy stuff so I set 2.0-alpha-3 (example). But
> now I want to prepare for 2.0.6 and want to run dependency:analyze
> and I
> want 2.0-alpha-4, I have to change my pluginManagement. I guess a
> way to
> override PMgt from the CLI would be sufficient here.
>
You can actually do this (yet another not well documented thing):
mvn org.apache.maven.plugins:maven-dependency-plugin:2.0-alpha-4:analyze
It's pretty grotesque - and I think better ways to manage pure CLI
plugins vs lifecycle ones in terms of versioning are definitely
needed. We had a stab with plugin-registry, but it wasn't all that
successful. It's actually a whole category of use cases to revise -
like how to easily select your repositories from the CLI when you
don't have a POM, etc. Thanks for bringing it up!
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: [discuss] Splitting the stable and unstable repositories
Posted by "Brian E. Fox" <br...@reply.infinity.nu>.
Brett,
I can see some logic to this as it's just another shade of grey between
the current snapshot repo and central. It does however feel a little
like a hack to work around some version ranging issues. I think
massembly is a good example of where this is needed, but perhaps mdep is
a case where it's not. This is still in "alpha" because there are more
goals planned to be added. While the plugin overall is alpha, some of
the original goals (copy/unpack, etc) are quite mature and very stable.
If we did this, it would raise the bar a little higher for people to get
useful functionality.
I think as mentioned in the assembly thread, that perhaps RELEASE isn't
what we need. Maybe we break that down into STABLE / UNSTABLE and if
there is no existing stable version, it would grab the latest unstable
one (essentially solving both massembly by getting 2.1 and mdep by
getting the newest until it is stable)
As for plugins that are bound in poms, I think the best practice should
be to use pluginManagement. It's the only way to guarantee
reproducibility and consistency across an organization. Every plugin I
use in my corp build is controlled this way and I really have no issues
with it.
(Slightly off topic, but related to my previous statement)
The only thing that is slightly annoying is when you have plugins with
goals that are both meant to be bound and some for the CLI. When you put
a plugin in to pluginManagement, this applies even to the CLI versions.
I'm not sure if/how we could make this better but here's the use case: I
use mdep to unpack and copy stuff so I set 2.0-alpha-3 (example). But
now I want to prepare for 2.0.6 and want to run dependency:analyze and I
want 2.0-alpha-4, I have to change my pluginManagement. I guess a way to
override PMgt from the CLI would be sufficient here.
--Brian
-----Original Message-----
From: Brett Porter [mailto:brett@apache.org]
Sent: Wednesday, March 28, 2007 7:46 PM
To: Maven Developers List
Subject: [discuss] Splitting the stable and unstable repositories
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.
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.
I would suggest this for future additions to central, but leave
anything currently there in place for backwards compat.
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?
- Brett
---------------------------------------------------------------------
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