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/04/21 22:57:18 UTC
Plugin version removal proposal
Hi,
I thought to gather up that massive thread I've just read, I could
throw out a quick proposal that might summarise it and serve as a
discussion point.
Things we know:
- the current situation is problematic
- we can't require versions for everything (particularly, the implied
plugins from the lifecycle - too much burden on the users)
- we can't put the versions in the maven installation (the POM must
be the definitive reference for how to build the software, changing
maven installations should have no effect - except for fixing bugs
and adding features some builds might require)
Side note:
- we *could* use the super POM. I don't think it's ideal in this case
(since you'd have to increment the model version too often to keep up
with the plugin releases), but it should be noted that the super POM
*is not* tied to the Maven version. If it changes, it should be tied
to the modelVersion.
The discussion also touched on the following, which I think are
separate issues:
- locking down versions at release time where they were not specified
(a more general problem, as it includes not only RELEASE/LATEST, but
ranges too).
- separation of "declaration" from "instantiation" for a POM.
So, here's what I propose:
- require the version in plugin definitions in the POM from
modelVersion 4.1.0+ (for 4.0.0 modelVersions, continue to allow the
RELEASE as the version).
- externalise all packagings/lifecycle definitions (with the
exception of 'pom', perhaps)
- make the user declare the plugin that contains the packaging they
want, including it's version (a plugin may contain more than one
packaging)
- make the packaging plugin declare the versions of the other
lifecycle plugins it uses (in the lifecycle itself, not the plugins pom)
- same for any overlaid lifecycles in plugins
- declared plugins and pluginManagement in the POM always wins over
the lifecycle.
- running from the CLI behaves as it does now
Now, while this could mean the jar packaging is in maven-jar-plugin,
etc. I would suggest that's too many plugins to change when the
compile plugin changes. So instead we could have the maven-java-
packages-plugin, v1.0 that has jar, war, ear, ejb, compile, surefire,
etc. all pinned to a known, tested set. If a user needs one of them
newer: plugin management.
This does mean that the java packaging plugin gets released more
often - perhaps even a function of all the other releases. It may be
a good idea for us to be able to make that plugin's build somehow a
part of the release of the other plugins, perhaps by making it driven
by repository metadata (ie, it might not be a real plugin, but a
virtual one, but still with a deterministic version to version
mapping). We could start off without this and just roadmap the plugin
like the others, however.
We should note that this does not tightly couple plugins in the same
way it has before which was problematic in m1. We are still
"programming to interfaces" - but the metadata wires up the right
versions of things. There is nothing in the plugin's pom tying it to
another plugin.
This solution is:
- deterministic
- easy to understand
- still as flexible as now for the user
- only a minimum imposition (5-9 lines) on a user
- only a minimum imposition on the developer/release process (the
java packaging plugin)
Thoughts?
Cheers,
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plugin version removal proposal
Posted by Brett Porter <br...@apache.org>.
On 22/04/2007, at 4:58 PM, Jason van Zyl wrote:
>> - require the version in plugin definitions in the POM from
>> modelVersion 4.1.0+ (for 4.0.0 modelVersions, continue to allow
>> the RELEASE as the version).
>
> +1
>
>> - externalise all packagings/lifecycle definitions (with the
>> exception of 'pom', perhaps)
>
> What does that mean exactly?
Take them out of core's components.xml and into the plugins.
>
>> - make the user declare the plugin that contains the packaging
>> they want, including it's version (a plugin may contain more than
>> one packaging)
>> - make the packaging plugin declare the versions of the other
>> lifecycle plugins it uses (in the lifecycle itself, not the
>> plugins pom)
>> - same for any overlaid lifecycles in plugins
>> - declared plugins and pluginManagement in the POM always wins
>> over the lifecycle.
>> - running from the CLI behaves as it does now
>>
>> Now, while this could mean the jar packaging is in maven-jar-
>> plugin, etc. I would suggest that's too many plugins to change
>> when the compile plugin changes. So instead we could have the
>> maven-java-packages-plugin, v1.0 that has jar, war, ear, ejb,
>> compile, surefire, etc. all pinned to a known, tested set. If a
>> user needs one of them newer: plugin management.
>>
>
> I think that's that's just way to coupled. I think providing the
> latest releases that are available in an easy way when people get
> started is the key but then the versions used must be easily
> visible somewhere so they can be changed because the second some
> one finds a bug and needs to change a version of something they
> will need an easy way to change this. Having to then build the
> maven-java-packages with altered versions would be not fun.
I was suggesting that using pluginManagement for an individual plugin
would still work. Would this resolve the objection?
>
> I think publishing the laundry list of a usable set and making a
> simple plugin to have that easily consumable is a great idea.
> Plugins depending on another artifact for version binding I think
> is bad. I think we need to publish releases, make them easy to find
> an be absorbed which leaves us in the situation of providing up-to-
> date information coupled with getting that information easily to
> users and then the user is in charge of version selection.
Seems like another good way. So a plugin takes a descriptor with a
set of artifacts (with versions) and pulls them all into the build
together (unless they already exist in plugin management which always
wins)?
I agree this is a better refinement of the same idea since it's
easier to construct. It might be best to take it to the next level
and build this in to Maven rather than it being a plugin for
consuming it (for ease of use). But that can also be a separate next
step.
>
>> We should note that this does not tightly couple plugins in the
>> same way it has before which was problematic in m1.
>
> If you bind that packaging set into the version resolution you are.
> That version set must be made available as a means for people to
> manage their own versions easily. We can update that often, and let
> people know, make tools, but ultimately you have to specify
> literally what you want so that when bad things happen there is
> only _one_ place to look to see how the version is resolved and
> that's the POM. Not some version set buried in a JAR file file
> somewhere, but the POMs used in your build. Period.
>
>> We are still "programming to interfaces" - but the metadata wires
>> up the right versions of things.
>
> -1
>
> That will need to severe maintenance problems.
>
> The POM becomes the authority. How we help people get the right
> versions can range from simple to complex, but ultimately any
> tooling done ultimately manifests itself as versions that land in
> the users POM.
I'm not really sure we understand each other here, since I am also
advocating the POM being the final authority, and we are both
proposing at least one level of indirection (one in plugin metadata,
one in a 'laundry list'). I think it's the same solution.
> So the difference may seem slight where the list is in a JAR,
> versus some resource in the repository but it means people can look
> at it with a web browser, cut and paste (eek) if they like, but
> most likely use a plugin to incorporate that into their build.
Ok, that makes sense. I agree having it easier to access is better.
So, it seems you are in general agreement with the proposal,
substituting the built plugin packs with a plugin that consumes
metadata and incorporates those versions into the build?
Diverging off this topic into the more general stuff...
>
> But the vast majority of our users are in a group situation and
> will have a parent POM with this information. If the
> pluginManagement section is more verbose then we can come up with
> something else.
Having to bump the parent POM all the time is an equal maintenance
nightmare that needs to be resolved.
>
> The bottom line is that I'm for less magic internally, betting
> tooling for initial setup, and making the POM more literal. By that
> I mean if someone specified a version of something there would be
> no strange reason that a different version was yanked in. For it to
> become the only source of version information and I think that's
> the only way things will be truly deterministic.
No disagreement there.
>
> Even if it become something where defaults were taken by reference
> and not resolution. And by that I mean versions of anything could
> be pulled in by consuming a reference to an xml file containing
> versions of things versus versions of artifacts requiring artifact
> resolution itself. And this would really only be required for first
> time users in the archetype:create and play scenerio. Anyone with a
> real build would specify everything.
This sounds way to extreme and limiting. You seem to be extending the
necessity to be explicit on plugin versions to the whole dependency
mechanism which I don't believe is true. But let's tackle these one
at a time.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plugin version removal proposal
Posted by Jason van Zyl <ja...@maven.org>.
On 21 Apr 07, at 4:57 PM 21 Apr 07, Brett Porter wrote:
> Hi,
>
> I thought to gather up that massive thread I've just read, I could
> throw out a quick proposal that might summarise it and serve as a
> discussion point.
>
> Things we know:
> - the current situation is problematic
> - we can't require versions for everything (particularly, the
> implied plugins from the lifecycle - too much burden on the users)
> - we can't put the versions in the maven installation (the POM must
> be the definitive reference for how to build the software, changing
> maven installations should have no effect - except for fixing bugs
> and adding features some builds might require)
>
> Side note:
> - we *could* use the super POM. I don't think it's ideal in this
> case (since you'd have to increment the model version too often to
> keep up with the plugin releases), but it should be noted that the
> super POM *is not* tied to the Maven version. If it changes, it
> should be tied to the modelVersion.
>
Yah, this is just a bad idea.
> The discussion also touched on the following, which I think are
> separate issues:
> - locking down versions at release time where they were not
> specified (a more general problem, as it includes not only RELEASE/
> LATEST, but ranges too).
> - separation of "declaration" from "instantiation" for a POM.
>
> So, here's what I propose:
> - require the version in plugin definitions in the POM from
> modelVersion 4.1.0+ (for 4.0.0 modelVersions, continue to allow the
> RELEASE as the version).
+1
Nothing can break behavior with the current versions of the POM in
widespread use if that wasn't clear. Changing that would be a nightmare.
> - externalise all packagings/lifecycle definitions (with the
> exception of 'pom', perhaps)
What does that mean exactly?
> - make the user declare the plugin that contains the packaging they
> want, including it's version (a plugin may contain more than one
> packaging)
> - make the packaging plugin declare the versions of the other
> lifecycle plugins it uses (in the lifecycle itself, not the plugins
> pom)
> - same for any overlaid lifecycles in plugins
> - declared plugins and pluginManagement in the POM always wins over
> the lifecycle.
> - running from the CLI behaves as it does now
>
> Now, while this could mean the jar packaging is in maven-jar-
> plugin, etc. I would suggest that's too many plugins to change when
> the compile plugin changes. So instead we could have the maven-java-
> packages-plugin, v1.0 that has jar, war, ear, ejb, compile,
> surefire, etc. all pinned to a known, tested set. If a user needs
> one of them newer: plugin management.
>
I think that's that's just way to coupled. I think providing the
latest releases that are available in an easy way when people get
started is the key but then the versions used must be easily visible
somewhere so they can be changed because the second some one finds a
bug and needs to change a version of something they will need an easy
way to change this. Having to then build the maven-java-packages with
altered versions would be not fun.
I think publishing the laundry list of a usable set and making a
simple plugin to have that easily consumable is a great idea. Plugins
depending on another artifact for version binding I think is bad. I
think we need to publish releases, make them easy to find an be
absorbed which leaves us in the situation of providing up-to-date
information coupled with getting that information easily to users and
then the user is in charge of version selection.
> This does mean that the java packaging plugin gets released more
> often - perhaps even a function of all the other releases. It may
> be a good idea for us to be able to make that plugin's build
> somehow a part of the release of the other plugins, perhaps by
> making it driven by repository metadata (ie, it might not be a real
> plugin, but a virtual one, but still with a deterministic version
> to version mapping). We could start off without this and just
> roadmap the plugin like the others, however.
>
The laundry list can simply be a file in the repository that can be
found and utilized to augment POMs, but otherwise not a part of
version resolution.
> We should note that this does not tightly couple plugins in the
> same way it has before which was problematic in m1.
If you bind that packaging set into the version resolution you are.
That version set must be made available as a means for people to
manage their own versions easily. We can update that often, and let
people know, make tools, but ultimately you have to specify literally
what you want so that when bad things happen there is only _one_
place to look to see how the version is resolved and that's the POM.
Not some version set buried in a JAR file file somewhere, but the
POMs used in your build. Period.
> We are still "programming to interfaces" - but the metadata wires
> up the right versions of things.
-1
That will need to severe maintenance problems.
The POM becomes the authority. How we help people get the right
versions can range from simple to complex, but ultimately any tooling
done ultimately manifests itself as versions that land in the users POM.
> There is nothing in the plugin's pom tying it to another plugin.
>
> This solution is:
> - deterministic
> - easy to understand
> - still as flexible as now for the user
> - only a minimum imposition (5-9 lines) on a user
> - only a minimum imposition on the developer/release process (the
> java packaging plugin)
>
> Thoughts?
That's not deterministic, nor would it be easy to understand.
It wouldn't be deterministic because our dependency resolution is not
deterministic so if someone needed a new artifact containing the
package map we are prey to all the problems we have now.
It is also not simple because it is bound into the general artifact
resolution mechanism itself to get version information.
What is simple is that what's in your POM rules with no other
mechanism involved.
How this ultimately manifests itself I'm not 100% sure. But I'm
certain that we need to provide the information easily about versions
of plugins and then remove ourselves from the equation.
For an organization this would be pretty easy to setup in a default
place. We can provide a reference to the defaults but no one in their
right mind should have a group build that doesn't have these versions
spec'd.
So the difference may seem slight where the list is in a JAR, versus
some resource in the repository but it means people can look at it
with a web browser, cut and paste (eek) if they like, but most likely
use a plugin to incorporate that into their build.
But the vast majority of our users are in a group situation and will
have a parent POM with this information. If the pluginManagement
section is more verbose then we can come up with something else.
The bottom line is that I'm for less magic internally, betting
tooling for initial setup, and making the POM more literal. By that I
mean if someone specified a version of something there would be no
strange reason that a different version was yanked in. For it to
become the only source of version information and I think that's the
only way things will be truly deterministic.
Even if it become something where defaults were taken by reference
and not resolution. And by that I mean versions of anything could be
pulled in by consuming a reference to an xml file containing versions
of things versus versions of artifacts requiring artifact resolution
itself. And this would really only be required for first time users
in the archetype:create and play scenerio. Anyone with a real build
would specify everything.
Jason.
>
> Cheers,
> 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: Plugin version removal proposal
Posted by John Casey <ca...@gmail.com>.
I don't have too much to add to the proposal as Jason has revised it. I'm
not too wild about leaving the CLI invocations to RELEASE metadata...I think
this doesn't account too well for branched activity of plugins, nor for
snapshots (of branches, for that matter). I think we're going to have to
think about specifying something like a PluginManagement section in the
settings.xml for this sort of thing, in cases where the POM doesn't help
out.
As for tooling, I'd like to see sets of plugins used in a lifecycle mapping
together - say, the jar packaging - be bundled in a descriptor that's
available in the repository with versions pegged and known to work
together...then, have a plugin reference that descriptor, to inline those
version specifications into the current POM (I think that's what we've been
talking about). However, we'll also need to have some idea of how to migrate
from one version of the descriptor to another (tracking a diff of the
plugins/versions supplied).
Though, now that I'm thinking about this more, I can see a need to have the
lifecycle mappings be a little more plastic. We might want to update the jar
mapping to provide gpg plugin bindings, for example...without the need to
release an entire new version of Maven for that change. However, we don't
want users to have to reach out to the central repo just for the basic jar
lifecycle mapping. So, I'd suggest bundling the latest (and historical)
releases of such lifecycle mapping *artifacts* inside an internal repository
within the maven installation, with the super-POM referencing this internal
repository. If a user wants to update his POM to use the jar-1.4 packaging
but the highest release in the internal repository is jar-1.3, then Maven
goes to the central repository for this. It's not really related to plugin
versioning, but I do think this could be an important feature, particularly
to help less "mature" lifecycle mappings, when they come along. These
lifecycle mappings could be included as a build extension, but it will
require a change to the POM syntax to allow the packaging to become an
artifact reference (possibly with 'jar' mapping to '
org.apache.maven.packaging:jar:1.0' or something, in the maven-core-internal
repository).
Just my 2 cents.
-john
On 5/13/07, Brett Porter <br...@apache.org> wrote:
>
> Regrettably, I was a bit out of it and forget to bring this one up
> f2f. Can we revisit this proposal with the change mentioned?
>
> On 03/05/2007, at 4:31 AM, Jason van Zyl wrote:
>
> > Yup, we have two long slots at the TC offices at j1. 14 hours in
> > total and I would like to talk about plugins, and artifact resolution.
> >
> > Jason.
> >
> > On 3 May 07, at 6:42 AM 3 May 07, Brett Porter wrote:
> >
> >> Any other thoughts on this proposal, given that we replace the
> >> packaging plugin concept with a descriptor instead?
> >>
> >> - Brett
> >>
> >> On 21/04/2007, at 10:57 PM, Brett Porter wrote:
> >>
> >>> Hi,
> >>>
> >>> I thought to gather up that massive thread I've just read, I
> >>> could throw out a quick proposal that might summarise it and
> >>> serve as a discussion point.
> >>>
> >>> Things we know:
> >>> - the current situation is problematic
> >>> - we can't require versions for everything (particularly, the
> >>> implied plugins from the lifecycle - too much burden on the users)
> >>> - we can't put the versions in the maven installation (the POM
> >>> must be the definitive reference for how to build the software,
> >>> changing maven installations should have no effect - except for
> >>> fixing bugs and adding features some builds might require)
> >>>
> >>> Side note:
> >>> - we *could* use the super POM. I don't think it's ideal in this
> >>> case (since you'd have to increment the model version too often
> >>> to keep up with the plugin releases), but it should be noted that
> >>> the super POM *is not* tied to the Maven version. If it changes,
> >>> it should be tied to the modelVersion.
> >>>
> >>> The discussion also touched on the following, which I think are
> >>> separate issues:
> >>> - locking down versions at release time where they were not
> >>> specified (a more general problem, as it includes not only
> >>> RELEASE/LATEST, but ranges too).
> >>> - separation of "declaration" from "instantiation" for a POM.
> >>>
> >>> So, here's what I propose:
> >>> - require the version in plugin definitions in the POM from
> >>> modelVersion 4.1.0+ (for 4.0.0 modelVersions, continue to allow
> >>> the RELEASE as the version).
> >>> - externalise all packagings/lifecycle definitions (with the
> >>> exception of 'pom', perhaps)
> >>> - make the user declare the plugin that contains the packaging
> >>> they want, including it's version (a plugin may contain more than
> >>> one packaging)
> >>> - make the packaging plugin declare the versions of the other
> >>> lifecycle plugins it uses (in the lifecycle itself, not the
> >>> plugins pom)
> >>> - same for any overlaid lifecycles in plugins
> >>> - declared plugins and pluginManagement in the POM always wins
> >>> over the lifecycle.
> >>> - running from the CLI behaves as it does now
> >>>
> >>> Now, while this could mean the jar packaging is in maven-jar-
> >>> plugin, etc. I would suggest that's too many plugins to change
> >>> when the compile plugin changes. So instead we could have the
> >>> maven-java-packages-plugin, v1.0 that has jar, war, ear, ejb,
> >>> compile, surefire, etc. all pinned to a known, tested set. If a
> >>> user needs one of them newer: plugin management.
> >>>
> >>> This does mean that the java packaging plugin gets released more
> >>> often - perhaps even a function of all the other releases. It may
> >>> be a good idea for us to be able to make that plugin's build
> >>> somehow a part of the release of the other plugins, perhaps by
> >>> making it driven by repository metadata (ie, it might not be a
> >>> real plugin, but a virtual one, but still with a deterministic
> >>> version to version mapping). We could start off without this and
> >>> just roadmap the plugin like the others, however.
> >>>
> >>> We should note that this does not tightly couple plugins in the
> >>> same way it has before which was problematic in m1. We are still
> >>> "programming to interfaces" - but the metadata wires up the right
> >>> versions of things. There is nothing in the plugin's pom tying it
> >>> to another plugin.
> >>>
> >>> This solution is:
> >>> - deterministic
> >>> - easy to understand
> >>> - still as flexible as now for the user
> >>> - only a minimum imposition (5-9 lines) on a user
> >>> - only a minimum imposition on the developer/release process (the
> >>> java packaging plugin)
> >>>
> >>> Thoughts?
> >>>
> >>> Cheers,
> >>> 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
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > 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
>
>
--
John Casey
---
Maven Developer (http://maven.apache.org)
---
Blog: http://www.ejlife.net/blogs/buildchimp
Re: Plugin version removal proposal
Posted by Brett Porter <br...@apache.org>.
Regrettably, I was a bit out of it and forget to bring this one up
f2f. Can we revisit this proposal with the change mentioned?
On 03/05/2007, at 4:31 AM, Jason van Zyl wrote:
> Yup, we have two long slots at the TC offices at j1. 14 hours in
> total and I would like to talk about plugins, and artifact resolution.
>
> Jason.
>
> On 3 May 07, at 6:42 AM 3 May 07, Brett Porter wrote:
>
>> Any other thoughts on this proposal, given that we replace the
>> packaging plugin concept with a descriptor instead?
>>
>> - Brett
>>
>> On 21/04/2007, at 10:57 PM, Brett Porter wrote:
>>
>>> Hi,
>>>
>>> I thought to gather up that massive thread I've just read, I
>>> could throw out a quick proposal that might summarise it and
>>> serve as a discussion point.
>>>
>>> Things we know:
>>> - the current situation is problematic
>>> - we can't require versions for everything (particularly, the
>>> implied plugins from the lifecycle - too much burden on the users)
>>> - we can't put the versions in the maven installation (the POM
>>> must be the definitive reference for how to build the software,
>>> changing maven installations should have no effect - except for
>>> fixing bugs and adding features some builds might require)
>>>
>>> Side note:
>>> - we *could* use the super POM. I don't think it's ideal in this
>>> case (since you'd have to increment the model version too often
>>> to keep up with the plugin releases), but it should be noted that
>>> the super POM *is not* tied to the Maven version. If it changes,
>>> it should be tied to the modelVersion.
>>>
>>> The discussion also touched on the following, which I think are
>>> separate issues:
>>> - locking down versions at release time where they were not
>>> specified (a more general problem, as it includes not only
>>> RELEASE/LATEST, but ranges too).
>>> - separation of "declaration" from "instantiation" for a POM.
>>>
>>> So, here's what I propose:
>>> - require the version in plugin definitions in the POM from
>>> modelVersion 4.1.0+ (for 4.0.0 modelVersions, continue to allow
>>> the RELEASE as the version).
>>> - externalise all packagings/lifecycle definitions (with the
>>> exception of 'pom', perhaps)
>>> - make the user declare the plugin that contains the packaging
>>> they want, including it's version (a plugin may contain more than
>>> one packaging)
>>> - make the packaging plugin declare the versions of the other
>>> lifecycle plugins it uses (in the lifecycle itself, not the
>>> plugins pom)
>>> - same for any overlaid lifecycles in plugins
>>> - declared plugins and pluginManagement in the POM always wins
>>> over the lifecycle.
>>> - running from the CLI behaves as it does now
>>>
>>> Now, while this could mean the jar packaging is in maven-jar-
>>> plugin, etc. I would suggest that's too many plugins to change
>>> when the compile plugin changes. So instead we could have the
>>> maven-java-packages-plugin, v1.0 that has jar, war, ear, ejb,
>>> compile, surefire, etc. all pinned to a known, tested set. If a
>>> user needs one of them newer: plugin management.
>>>
>>> This does mean that the java packaging plugin gets released more
>>> often - perhaps even a function of all the other releases. It may
>>> be a good idea for us to be able to make that plugin's build
>>> somehow a part of the release of the other plugins, perhaps by
>>> making it driven by repository metadata (ie, it might not be a
>>> real plugin, but a virtual one, but still with a deterministic
>>> version to version mapping). We could start off without this and
>>> just roadmap the plugin like the others, however.
>>>
>>> We should note that this does not tightly couple plugins in the
>>> same way it has before which was problematic in m1. We are still
>>> "programming to interfaces" - but the metadata wires up the right
>>> versions of things. There is nothing in the plugin's pom tying it
>>> to another plugin.
>>>
>>> This solution is:
>>> - deterministic
>>> - easy to understand
>>> - still as flexible as now for the user
>>> - only a minimum imposition (5-9 lines) on a user
>>> - only a minimum imposition on the developer/release process (the
>>> java packaging plugin)
>>>
>>> Thoughts?
>>>
>>> Cheers,
>>> 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
>>
>>
>
>
> ---------------------------------------------------------------------
> 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: Plugin version removal proposal
Posted by Jason van Zyl <ja...@maven.org>.
Yup, we have two long slots at the TC offices at j1. 14 hours in
total and I would like to talk about plugins, and artifact resolution.
Jason.
On 3 May 07, at 6:42 AM 3 May 07, Brett Porter wrote:
> Any other thoughts on this proposal, given that we replace the
> packaging plugin concept with a descriptor instead?
>
> - Brett
>
> On 21/04/2007, at 10:57 PM, Brett Porter wrote:
>
>> Hi,
>>
>> I thought to gather up that massive thread I've just read, I could
>> throw out a quick proposal that might summarise it and serve as a
>> discussion point.
>>
>> Things we know:
>> - the current situation is problematic
>> - we can't require versions for everything (particularly, the
>> implied plugins from the lifecycle - too much burden on the users)
>> - we can't put the versions in the maven installation (the POM
>> must be the definitive reference for how to build the software,
>> changing maven installations should have no effect - except for
>> fixing bugs and adding features some builds might require)
>>
>> Side note:
>> - we *could* use the super POM. I don't think it's ideal in this
>> case (since you'd have to increment the model version too often to
>> keep up with the plugin releases), but it should be noted that the
>> super POM *is not* tied to the Maven version. If it changes, it
>> should be tied to the modelVersion.
>>
>> The discussion also touched on the following, which I think are
>> separate issues:
>> - locking down versions at release time where they were not
>> specified (a more general problem, as it includes not only RELEASE/
>> LATEST, but ranges too).
>> - separation of "declaration" from "instantiation" for a POM.
>>
>> So, here's what I propose:
>> - require the version in plugin definitions in the POM from
>> modelVersion 4.1.0+ (for 4.0.0 modelVersions, continue to allow
>> the RELEASE as the version).
>> - externalise all packagings/lifecycle definitions (with the
>> exception of 'pom', perhaps)
>> - make the user declare the plugin that contains the packaging
>> they want, including it's version (a plugin may contain more than
>> one packaging)
>> - make the packaging plugin declare the versions of the other
>> lifecycle plugins it uses (in the lifecycle itself, not the
>> plugins pom)
>> - same for any overlaid lifecycles in plugins
>> - declared plugins and pluginManagement in the POM always wins
>> over the lifecycle.
>> - running from the CLI behaves as it does now
>>
>> Now, while this could mean the jar packaging is in maven-jar-
>> plugin, etc. I would suggest that's too many plugins to change
>> when the compile plugin changes. So instead we could have the
>> maven-java-packages-plugin, v1.0 that has jar, war, ear, ejb,
>> compile, surefire, etc. all pinned to a known, tested set. If a
>> user needs one of them newer: plugin management.
>>
>> This does mean that the java packaging plugin gets released more
>> often - perhaps even a function of all the other releases. It may
>> be a good idea for us to be able to make that plugin's build
>> somehow a part of the release of the other plugins, perhaps by
>> making it driven by repository metadata (ie, it might not be a
>> real plugin, but a virtual one, but still with a deterministic
>> version to version mapping). We could start off without this and
>> just roadmap the plugin like the others, however.
>>
>> We should note that this does not tightly couple plugins in the
>> same way it has before which was problematic in m1. We are still
>> "programming to interfaces" - but the metadata wires up the right
>> versions of things. There is nothing in the plugin's pom tying it
>> to another plugin.
>>
>> This solution is:
>> - deterministic
>> - easy to understand
>> - still as flexible as now for the user
>> - only a minimum imposition (5-9 lines) on a user
>> - only a minimum imposition on the developer/release process (the
>> java packaging plugin)
>>
>> Thoughts?
>>
>> Cheers,
>> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: Plugin version removal proposal
Posted by Raphaël Piéroni <ra...@gmail.com>.
2007/5/3, Brett Porter <br...@apache.org>:
> Any other thoughts on this proposal, given that we replace the
> packaging plugin concept with a descriptor instead?
Do that mean anything for the archetypes? i use maven-plugin
packaging to have the group metadata for the archetypes.
Raphaël
>
> - Brett
>
> On 21/04/2007, at 10:57 PM, Brett Porter wrote:
>
> > Hi,
> >
> > I thought to gather up that massive thread I've just read, I could
> > throw out a quick proposal that might summarise it and serve as a
> > discussion point.
> >
> > Things we know:
> > - the current situation is problematic
> > - we can't require versions for everything (particularly, the
> > implied plugins from the lifecycle - too much burden on the users)
> > - we can't put the versions in the maven installation (the POM must
> > be the definitive reference for how to build the software, changing
> > maven installations should have no effect - except for fixing bugs
> > and adding features some builds might require)
> >
> > Side note:
> > - we *could* use the super POM. I don't think it's ideal in this
> > case (since you'd have to increment the model version too often to
> > keep up with the plugin releases), but it should be noted that the
> > super POM *is not* tied to the Maven version. If it changes, it
> > should be tied to the modelVersion.
> >
> > The discussion also touched on the following, which I think are
> > separate issues:
> > - locking down versions at release time where they were not
> > specified (a more general problem, as it includes not only RELEASE/
> > LATEST, but ranges too).
> > - separation of "declaration" from "instantiation" for a POM.
> >
> > So, here's what I propose:
> > - require the version in plugin definitions in the POM from
> > modelVersion 4.1.0+ (for 4.0.0 modelVersions, continue to allow the
> > RELEASE as the version).
> > - externalise all packagings/lifecycle definitions (with the
> > exception of 'pom', perhaps)
> > - make the user declare the plugin that contains the packaging they
> > want, including it's version (a plugin may contain more than one
> > packaging)
> > - make the packaging plugin declare the versions of the other
> > lifecycle plugins it uses (in the lifecycle itself, not the plugins
> > pom)
> > - same for any overlaid lifecycles in plugins
> > - declared plugins and pluginManagement in the POM always wins over
> > the lifecycle.
> > - running from the CLI behaves as it does now
> >
> > Now, while this could mean the jar packaging is in maven-jar-
> > plugin, etc. I would suggest that's too many plugins to change when
> > the compile plugin changes. So instead we could have the maven-java-
> > packages-plugin, v1.0 that has jar, war, ear, ejb, compile,
> > surefire, etc. all pinned to a known, tested set. If a user needs
> > one of them newer: plugin management.
> >
> > This does mean that the java packaging plugin gets released more
> > often - perhaps even a function of all the other releases. It may
> > be a good idea for us to be able to make that plugin's build
> > somehow a part of the release of the other plugins, perhaps by
> > making it driven by repository metadata (ie, it might not be a real
> > plugin, but a virtual one, but still with a deterministic version
> > to version mapping). We could start off without this and just
> > roadmap the plugin like the others, however.
> >
> > We should note that this does not tightly couple plugins in the
> > same way it has before which was problematic in m1. We are still
> > "programming to interfaces" - but the metadata wires up the right
> > versions of things. There is nothing in the plugin's pom tying it
> > to another plugin.
> >
> > This solution is:
> > - deterministic
> > - easy to understand
> > - still as flexible as now for the user
> > - only a minimum imposition (5-9 lines) on a user
> > - only a minimum imposition on the developer/release process (the
> > java packaging plugin)
> >
> > Thoughts?
> >
> > Cheers,
> > 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: Plugin version removal proposal
Posted by Brett Porter <br...@apache.org>.
Any other thoughts on this proposal, given that we replace the
packaging plugin concept with a descriptor instead?
- Brett
On 21/04/2007, at 10:57 PM, Brett Porter wrote:
> Hi,
>
> I thought to gather up that massive thread I've just read, I could
> throw out a quick proposal that might summarise it and serve as a
> discussion point.
>
> Things we know:
> - the current situation is problematic
> - we can't require versions for everything (particularly, the
> implied plugins from the lifecycle - too much burden on the users)
> - we can't put the versions in the maven installation (the POM must
> be the definitive reference for how to build the software, changing
> maven installations should have no effect - except for fixing bugs
> and adding features some builds might require)
>
> Side note:
> - we *could* use the super POM. I don't think it's ideal in this
> case (since you'd have to increment the model version too often to
> keep up with the plugin releases), but it should be noted that the
> super POM *is not* tied to the Maven version. If it changes, it
> should be tied to the modelVersion.
>
> The discussion also touched on the following, which I think are
> separate issues:
> - locking down versions at release time where they were not
> specified (a more general problem, as it includes not only RELEASE/
> LATEST, but ranges too).
> - separation of "declaration" from "instantiation" for a POM.
>
> So, here's what I propose:
> - require the version in plugin definitions in the POM from
> modelVersion 4.1.0+ (for 4.0.0 modelVersions, continue to allow the
> RELEASE as the version).
> - externalise all packagings/lifecycle definitions (with the
> exception of 'pom', perhaps)
> - make the user declare the plugin that contains the packaging they
> want, including it's version (a plugin may contain more than one
> packaging)
> - make the packaging plugin declare the versions of the other
> lifecycle plugins it uses (in the lifecycle itself, not the plugins
> pom)
> - same for any overlaid lifecycles in plugins
> - declared plugins and pluginManagement in the POM always wins over
> the lifecycle.
> - running from the CLI behaves as it does now
>
> Now, while this could mean the jar packaging is in maven-jar-
> plugin, etc. I would suggest that's too many plugins to change when
> the compile plugin changes. So instead we could have the maven-java-
> packages-plugin, v1.0 that has jar, war, ear, ejb, compile,
> surefire, etc. all pinned to a known, tested set. If a user needs
> one of them newer: plugin management.
>
> This does mean that the java packaging plugin gets released more
> often - perhaps even a function of all the other releases. It may
> be a good idea for us to be able to make that plugin's build
> somehow a part of the release of the other plugins, perhaps by
> making it driven by repository metadata (ie, it might not be a real
> plugin, but a virtual one, but still with a deterministic version
> to version mapping). We could start off without this and just
> roadmap the plugin like the others, however.
>
> We should note that this does not tightly couple plugins in the
> same way it has before which was problematic in m1. We are still
> "programming to interfaces" - but the metadata wires up the right
> versions of things. There is nothing in the plugin's pom tying it
> to another plugin.
>
> This solution is:
> - deterministic
> - easy to understand
> - still as flexible as now for the user
> - only a minimum imposition (5-9 lines) on a user
> - only a minimum imposition on the developer/release process (the
> java packaging plugin)
>
> Thoughts?
>
> Cheers,
> 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