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 <[EMAIL PROTECTED]> 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: [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] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- John Casey --- Maven Developer (http://maven.apache.org) --- Blog: http://www.ejlife.net/blogs/buildchimp
