maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Raphaël Piéroni" <raphaelpier...@gmail.com>
Subject Re: Plugin version removal proposal
Date Thu, 03 May 2007 17:54:10 GMT
2007/5/3, Brett Porter <brett@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
>
>
Mime
View raw message