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