On Tue, Nov 26, 2013 at 05:05:40PM +0100, Malte Skoruppa wrote: [snip] > I am not so intent on having the 'latest-and-greatest' plugin as you > might think. It's more that I would like to stick to the default > configuration unless I have good reason not to do so. It's really just > that I find it kind of weird that if I want to deviate from one default > (the Java version), I also *have* to deviate from another (the plugin > version).
Think of it this way: org.apache.maven.plugins:maven-compiler-plugin does not refer to a single plugin, but to the whole family of versions of that plugin. It's an incomplete set of coordinates, specifying a line rather than a point. The weirdness is inevitable, because in order to configure the plugin you have to specify which plugin you are configuring. It's a minor pain in the neck, flowing from the way Maven needs to work. I dislike it too, but one gets used to it. Maven deals in artifacts, not lines of development. I'm coming around to the position that grooming POMs to update the versions of all specified dependencies (packages *and* plugins) is just one of the things one does right after release, when beginning the next development cycle. dependency:analyze is a good source of suggestions. That way you regularly catch up with recent developments elsewhere, and can still pin down versions within a development cycle. Within each cycle I'd tend to hold versions stable unless someone releases an update that I really need. BTW, speaking of weirdness: generated POMs *do* specify the version of m-compiler-p, by *not* specifying it. There's a built-in set of defaults(1) buried inside Maven, which specify much of the not-otherwise-specified. Someone already mentioned this, but it may have sped by unnoticed. ------------------- 1. All together, now: "convention over configuration!" -- Mark H. Wood, Lead System Programmer mw...@iupui.edu Machines should not be friendly. Machines should be obedient.
signature.asc
Description: Digital signature
