[
http://jira.codehaus.org/browse/MNG-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=242128#action_242128
]
Ian Brandt commented on MNG-2805:
---------------------------------
Just to add a real world use case I found my way here looking for a way to
disable the execution of the maven-antlr3-plugin when an "IDE" profile is
active, signifying the ANTLRv3 IDE Eclipse plugin is in use. The issue is the
M2Eclipse/maven-antlr3-plugin and ANTLRv3 IDE Eclipse plugins tend to trip over
each other, as they both try to create the same generated source files. It
would be easy to disable the ANTLRv3 IDE builder in Eclipse, but it offers the
added benefit of programmatically marking the generated resources as "derived".
This doesn't happen if M2Eclipse/maven-antlr3-plugin beats it to the punch
after a {{clean}}.
M2Eclipse lets you set an active profile in project level preferences, which
can be shared by checking in {{.settings/org.maven.ide.eclipse.prefs}}:
{noformat}
#Thu Nov 04 11:24:30 PDT 2010
activeProfiles=ide
eclipse.preferences.version=1
fullBuildGoals=process-test-resources
includeModules=false
resolveWorkspaceProjects=true
resourceFilterGoals=process-resources resources\:testResources
skipCompilerPlugin=true
version=1
{noformat}
Then a workaround similar to that referenced by Aleksander above works okay,
where the maven-antlr3-plugin is only declared in a profile that is active
whenever the "ide" profile is not:
{noformat}
<profiles>
<profile>
<id>ide</id>
<activation>
<activeByDefault>false</activeByDefault>
</activation>
<properties>
<ide>true</ide>
</properties>
</profile>
<profile>
<id>antlr</id>
<activation>
<property>
<name>!ide</name>
</property>
</activation>
<build>
<plugins>
<plugin>
<groupId>org.antlr</groupId>
<artifactId>antlr3-maven-plugin</artifactId>
<version>3.2</version>
<executions>
<execution>
<goals>
<goal>antlr</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</build>
</profile>
</profiles>
{noformat}
The {{<disableExecution>}} or {{<disablePlugin>}} additions proposed would
certainly seem to offer a more straightforward and succinct solution.
> Provide mechanism for suppressing inherited/injected/mapped mojo binding
> ------------------------------------------------------------------------
>
> Key: MNG-2805
> URL: http://jira.codehaus.org/browse/MNG-2805
> Project: Maven 2 & 3
> Issue Type: New Feature
> Components: POM
> Affects Versions: 2.0.4
> Reporter: John Casey
> Fix For: Issues to be reviewed for 3.x
>
>
> In some cases, a mojo should be suppressed from the build process. If this
> mojo binding comes from a parent POM or a lifecycle mapping, it's not
> possible to simply comment out that mojo binding. Currently this sort of
> functionality is left to the individual plugins to implement as parameters
> that cause each mojo to bow out. This use case is common enough in large
> development environments (for addressing the 80% with no customization, but
> allowing the remaining 20% the control to use the same parent POM with
> subtractions) to warrant a built-in suppression/disabling functionality.
> Suppression should be available by plugin or by plugin-execution. To suppress
> bindings from the packaging-mapping, the default executionId 'default' can be
> used.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
