2008/11/10 Christian Schulte <[EMAIL PROTECTED]> > Stephen Connolly wrote: > > So, how did we get here: the use case that triggered all of this is > > specifying a different configuration for the maven-compiler-plugin when > > executed during the test-compile phase (to allow unit tests to be > compiled > > with Java 1.5, while the main code is compiled with 1.4) > > Until now, this information was missing to this thread. See the original > mail starting this thread. >
> "I'd like to be able to configure the default execution of a plugin > within an execution instead of doing it through the main plugin > configuration." > > > This is a valid use case (and a work around of adding testSource and > > testTarget parameters has been implemented in the > maven-compiler-plugin... > > but it will arrise in other cases with other plugins) > > You are the only person who brought that up on this thread and I am glad > you did. However, I still think the original author was talking about > something else. OK, you are correct... I got confused because the thread about configuring different executions of the compiler plugin differently got noisy at or around the same time as this thread got noisy, and I assumed that they were related.... they are related but just not intentially ;-) > > So the question being asked is: "What id do we assign to executions being > > introduced via the packaging's lifecycle bindings?" > > > > The id cannot be "default" as we have multiple bindings of the same > plugin > > to different phases... which is why I came up with the proposal of: > > > > lifecycle:[packaging]:[phase] > > > > and allowing * to match all of either packaging or phase. > > > It wasn't me proposing "default" at first! You have proven us all wrong > about that id (default, default-execution-id, > #groupId:artifactId:sequenceNumber, default-execution-compile, > default-execution-testCompile). And you presented a solution which seems > to be correct. I was already convinced by your first mail. > > > As to what about standalone: well they use the default configuration for > the > > plugin. If you think about it, executions are attached to the lifecycle > for > > a reason. if you just execute compiler:compile raw, you will not be able > to > > compile as the raw execution does not give the foo plugin a chance to > attach > > the additional source folders for the generated classes that it created. > > Maybe I was not clear about this standalone thing. This here > > mvn ide:eclipse > mvn ide:netbeans > mvn ide:eclipse ide:netbeans > > is also a valid use case. There is no way to configure different goals > differently via the plugin's main configuration if these goals share the > same parameters. > I agree that there is no way to configure these command line executions directly... I just disagree that one should be able to configure them separately ;-) My first point is that unless plugins are invoked through an execution bound to a lifecycle phase, you have no guarantee that the reactor has all the relevant information to hand. Take for example, the idea:idea or eclipse:eclipse goals (this is partly a bad example but I'll explain why in a sec) Ideally, this goal should be attached to the compile phase, so that all the plugins that operator at the generate-sources, generate-resources, etc phases of the lifecycle get a chance to attach the folders that they produce to the list of source paths and resource paths. If we allow you to execute that goal from the cli, you'll get an incorrect environment because the plugins that generate source code have not been executed. When you think about it a bit more, what you are really asking for is the ability to define custom lifecycle phases (which moves away from maven's whole - there is a standard lifecycle - way of working... i.e. a bad thing) My solution would be to define profiles for these executions that you want to run from the command line... a profile can include a <build> section, and so can define a <defaultGoal>, and once you can tweak the executions inherited from the lifecycle, you can in essence turn off the long boring bits that you are trying to skip... you would in essence define that the defaultGoal for your fancyStuff profile would be compile, you'd turn off execution of the foo-plugin as it does not attach source but does a long download of validation rules, and turn off the compiler plugin as you're just generating ide files, and you'd do mvn -PfancyStuff it would have the goals you need defined as executions attached to the correct phases in the lifecycle... sorted in my view In fact you should be able to do this right now: <project xmlns="http://maven.apache.org/POM/4.0.0"; xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"; xsi:schemaLocation=" http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd";> <modelVersion>4.0.0</modelVersion> <groupId>foo</groupId> <artifactId>foo</artifactId> <version>1-SNAPSHOT</version> <packaging>pom</packaging> <profiles> <profile> <id>fancyStuff</id> <build> <defaultGoal>validate</defaultGoal> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-enforcer-plugin</artifactId> <executions> <execution> <id>enforce-build-tools</id> <phase>validate</phase> <goals> <goal>display-info</goal> </goals> </execution> </executions> </plugin> </plugins> </build> </profile> </profiles> </project> Yep, you can... in fact this is a better way of doing all those command-line tasks that are one-offs ;-) > > Well, I admit, this mixes up different things to look like the same but > originally this thread was about having the ability to configure the > default execution as an execution element in the pom and not to be > forced to use the main configuration. This also means that it makes a > configuration per goal(s) possible what is not possible using a plugin's > main configuration! > > For example: Have these two goals define a mojo parameter > "outputDirectory". If you would want to use different values per goal, > one could not do that using the plugin's main configuration and is > forced to introduce two different parameters like > "eclipseOutputDirectory" and "netbeansOutputDirectory". > > As I understand things, it would become possible to have that single > "outputDirectory" parameter be configured differently per goal. Which > does not prove your solution wrong, does it ? That there is no > standalone lifecycle does not mean that there could not be one with only > a single phase all command line goals get added to automatically. Leads to: > > <id>cli:*</id> > <goals> > <goal>ide:eclipse</goal> > </goals> > <configuration> > <outputDirectory>eclipse-value</outputDirectory> > </configuration> > > <id>cli:*</id> > <goals> > <goal>ide:netbeans</goal> > </goals> > <configuration> > <outputDirectory>netbeans-value</outputDirectory> > </configuration> > > <id>cli:*</id> > <goals> > <goal>ide:eclipse</goal> > <goal>ide:netbeans</goal> > </goals> > <configuration> > <outputDirectory>same-value-for-both</outputDirectory> > </configuration> > > And this would even work without such a standalone or cli lifecycle, I > think. Did I really get that completely wrong ? Anyway, thanks _a lot_ > for your time and for explaining things in detail. > No need, see the pom snippet from above... which should be adaptable to do anything you need! > > -- > Christian > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
