2007/5/3, Brett Porter <[EMAIL PROTECTED]>:
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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
