On Mon, 2006-03-20 at 09:44 -0600, Wayne Fay wrote: > Just a tiny comment... > > > > An execution is always an additional binding to the lifecycle, so it > > > doubles up when it is already bound through the presets for the > > > packaging. The only way to configure the presets is through the > > > configuration element in the plugin node itself (outside of > > > executions). Unfortunately, you only get one per plugin. > > > > The term "plugin node" doesn't really help me here. This is kind of > > what I was getting at. > > He is simply refering to the pom.xml <plugin> "xml node" itself. It > contains a single <configuration> element. You may schedule several > <execution> elements for a given plugin, but only one <configuration> > that applies across all executions of that plugin.
Below is another way to look at this. Note that I'm no Maven guru, so this might not be quite 100% correct.. Quick definition: * A plugin is a set of classes bundled into a jar. A plugin implements one or more "goals" that are specific tasks. When invoked, Maven * defines its fixed set of "phases". * creates a plugin representation in memory for each declared plugin (including the ones defined in the invisible root "super-pom"). The object is initialised using the plugin/configuration tag. However the plugin/execution/* tags are ignored for now. * executes the "packaging" logic, which creates links from various phases to "goals" of plugin objects. For example, packaging of "jar" sets up one set of phase->goal links while packaging of "war" sets up a different set of mappings. * processes the plugin/execution tags to add *extra* links from phases to the associated goals. Any <configuration> data in the execution tag overrides definitions associated directly with the plugin *for that link*. * executes its phases in order. At each phase, it executes the set of goals associated with the phase. There is no way to tell "jar" packaging to NOT link the maven-compiler-plugin's compile goal to the "compile" and "test-compile" phases; the only way to accomplish that sort of thing is to write your own packaging definition. In some cases you can configure the goal to just return when invoked; that depends on the particular plugin supporting that feature though. What Brett's suggestion does is to configure the maven-compiler-plugin to compile the main src but *not* the tests, by setting skip=true. The plugin/configuration entries controls which source version is used (1.3), resulting in *only* the main src being compiled (with 1.3) despite there being a link from phase test-compile to the plugin (because packaging=jar). A separate <execution> tag then links maven-compile-plugin to just the compile-tests phase, and the <configuration> within the execution is used to force source=1.5. Note that the effect is that the test-compile phase has goal maven-compiler-plugin:compile linked to it *twice*, once using the plugin/configuration settings and one with the plugin/execution/configuration settings. However the first invocation returns immediately as skip=true. As Brett said, it's a hack. But compiling the source with 1.3 and tests with 1.5 *is* a little unusual. I'd be very interested in knowing what Brett means by "fixed in svn". Perhaps the maven-compiler-plugin has a <disabled> option now?? I hope this info is more helpful than confusing. I also found getting my mind around Maven difficult at first; however I'm becoming more and more impressed with it as I get used to it. Congratulations Brett/Jason/Vincent/others, it's a very useful tool indeed. The maven book that's currently being created should help a lot when it's finished; it will be freely available online: http://mavenbook.xwiki.com/xwiki/bin/view/Main/Maven2Book Cheers, Simon --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
