maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brett Porter <br...@apache.org>
Subject Re: Plugin version removal proposal
Date Thu, 03 May 2007 10:42:15 GMT
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: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Mime
View raw message