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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
