On Mon, 2010-06-14 at 19:01 +0100, sebb wrote: > On 14/06/2010, Oleg Kalnichevski <ol...@apache.org> wrote: > > On Mon, 2010-06-14 at 17:54 +0100, sebb wrote: > > > On 14/06/2010, Oleg Kalnichevski <ol...@apache.org> wrote: > > > > On Mon, 2010-06-14 at 17:06 +0100, sebb wrote: > > > > > On 14/06/2010, Oleg Kalnichevski <ol...@apache.org> wrote: > > > > > > On Mon, 2010-06-14 at 16:28 +0100, sebb wrote: > > > > > > > On 14/06/2010, Oleg Kalnichevski <ol...@apache.org> wrote: > > > > > > > > On Mon, 2010-06-14 at 11:45 +0000, s...@apache.org wrote: > > > > > > > > > Author: sebb > > > > > > > > > Date: Mon Jun 14 11:45:02 2010 > > > > > > > > > New Revision: 954415 > > > > > > > > > > > > > > > > > > URL: http://svn.apache.org/viewvc?rev=954415&view=rev > > > > > > > > > Log: > > > > > > > > > Sort the pluginManagement section > > > > > > > > > > > > > > > > > > Modified: > > > > > > > > > httpcomponents/project/pom.xml > > > > > > > > > > > > > > > > > > Modified: httpcomponents/project/pom.xml > > > > > > > > > URL: > > http://svn.apache.org/viewvc/httpcomponents/project/pom.xml?rev=954415&r1=954414&r2=954415&view=diff > > > > > > > > > > > ============================================================================== > > > > > > > > > --- httpcomponents/project/pom.xml (original) > > > > > > > > > +++ httpcomponents/project/pom.xml Mon Jun 14 11:45:02 > > 2010 > > > > > > > > > @@ -272,6 +272,32 @@ > > > > > > > > > </plugins> > > > > > > > > > <pluginManagement> > > > > > > > > > <plugins> > > > > > > > > > + <!-- org.apache.maven.plugins, alpha order by > > artifact id --> > > > > > > > > > + <plugin> > > > > > > > > > + <groupId>org.apache.maven.plugins</groupId> > > > > > > > > > + <artifactId>maven-assembly-plugin</artifactId> > > > > > > > > > + <version>2.2-beta-5</version> > > > > > > > > > + </plugin> > > > > > > > > > + <plugin> > > > > > > > > > + <groupId>org.apache.maven.plugins</groupId> > > > > > > > > > + <artifactId>maven-antrun-plugin</artifactId> > > > > > > > > > + <version>1.4</version> > > > > > > > > > + </plugin> > > > > > > > > > + <plugin> > > > > > > > > > + <groupId>org.apache.maven.plugins</groupId> > > > > > > > > > + <artifactId>maven-clean-plugin</artifactId> > > > > > > > > > + <version>2.4.1</version> > > > > > > > > > + </plugin> > > > > > > > > > + <plugin> > > > > > > > > > + <groupId>org.apache.maven.plugins</groupId> > > > > > > > > > + <artifactId>maven-compiler-plugin</artifactId> > > > > > > > > > + <version>2.3.1</version> > > > > > > > > > + </plugin> > > > > > > > > > + <plugin> > > > > > > > > > + <groupId>org.apache.maven.plugins</groupId> > > > > > > > > > + <artifactId>maven-deploy-plugin</artifactId> > > > > > > > > > + <version>2.5</version> > > > > > > > > > + </plugin> > > > > > > > > > <plugin> > > > > > > > > > <groupId>org.apache.maven.plugins</groupId> > > > > > > > > > <artifactId>maven-gpg-plugin</artifactId> > > > > > > > > > > > > > > > > Sebastian > > > > > > > > > > > > > > > > While it is certainly a good idea to have versions of > > non-core Maven > > > > > > > > plugins explicitly set in POM, I am not sure it is the case > > for core > > > > > > > > plugins unless we also somehow enforce a very _specific_ > > Maven version > > > > > > > > that matches those core plugin version. > > > > > > > > > > > > > > > > Maven releases are tested against specific versions of core > > plugins and > > > > > > > > mixing things up may be as ugly as letting Maven always > > pick up the > > > > > > > > newest version. > > > > > > > > > > > > > > OK, but how does one know what is a core plugin and what is > > not? > > > > > > > > > > > > > > > > > > > > > > > > > Please see > > > > > > > > > > > > http://maven.apache.org/plugins/index.html > > > > > > > > > > > > > > > > Thanks. > > > > > > > > > > So in theory one should omit all plugin version specifications for > > > > > plugins that are in that list? > > > > > > > > > > > > > > > > > The very first section of plugin list is defined as 'core' > > > > --- > > > > Core plugins Plugins corresponding to default core phases <snip/> > > > > clean > > > > compiler > > > > deploy > > > > failsafe > > > > install > > > > resources > > > > site > > > > surefire > > > > verifier > > > > --- > > > > > > > > At the very least these plugins one ought not to mess with. > > > Well, we have to either override the site plugin version, or downgrade > > > maven-project-info-reports-plugin to a version that works with the old > > > site plugin. > > > > > > > A more > > > > definitive list with corresponding versions can be found in the so > > > > called superdom file (pom-4.0.0.xml in case of Maven 2.0.x) shipped > > with > > > > the maven uber jar. > > > > > > Thanks, that explains where the 2.0-beta-7 version for > > > maven-site-plugin comes from. > > > > > > > Only in extreme cases such as a known compatibility issue we should > > > > temporarily override those versions > > > > > > I don't think that is viable in the long term. > > > > > > > > > Why? > > Because if a non-core plugin works with a specific version of a core > plugin, it may break when using a different Maven version. >
Likewise, a plugin may break when used with a different version of Maven kernel. This can be especially severe if that happens to a core plugin. I could not care less if Clover gets all screwy as long as jars get built correctly. > > > Another approach (which would allow more uptodate plugins to be used) > > > would be to use the versions on the page: > > > > > > http://maven.apache.org/plugins/index.html > > > > > > We ought to be able to assume that those versions work together. > > > > > > > > > Yes, we _might_ be able to assume plugins are compatible with one > > another but I do not think we can assume compatibility with all > > different versions of Maven kernel out there. > > > > I think it is more reasonable to use core plugins that match the kernel > > version unless there is a good reason to do otherwise. > > In which case surely we have to specify the exact Maven version to use? > > Or am I missing something here? > And how exactly do you intend to do so, other than by stating in BUILDING.txt no one usually bothers to read? There is no point arguing any further. I stated my objection. If you think it is baseless, feel free to ignore it. Oleg --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@hc.apache.org For additional commands, e-mail: dev-h...@hc.apache.org
