maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <>
Subject Re: Plugin version removal proposal
Date Sun, 13 May 2007 23:34:28 GMT
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:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message