You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@maven.apache.org by "John Casey (JIRA)" <ji...@codehaus.org> on 2007/02/01 22:46:44 UTC
[jira] Created: (MNG-2805) Provide mechanism for suppressing
inherited/injected/mapped mojo binding
Provide mechanism for suppressing inherited/injected/mapped mojo binding
------------------------------------------------------------------------
Key: MNG-2805
URL: http://jira.codehaus.org/browse/MNG-2805
Project: Maven 2
Issue Type: New Feature
Components: POM
Affects Versions: 2.0.4
Reporter: John Casey
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
[jira] Commented: (MNG-2805) Provide mechanism for suppressing
inherited/injected/mapped mojo binding
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_86576 ]
John Casey commented on MNG-2805:
---------------------------------
See http://docs.codehaus.org/display/MAVEN/Suppression%2C+Ordering%2C+and+Replacement+of+Plugins+and+Mojos+Bindings for more info.
> Provide mechanism for suppressing inherited/injected/mapped mojo binding
> ------------------------------------------------------------------------
>
> Key: MNG-2805
> URL: http://jira.codehaus.org/browse/MNG-2805
> Project: Maven 2
> Issue Type: New Feature
> Components: POM
> Affects Versions: 2.0.4
> Reporter: John Casey
> Fix For: 2.1-alpha-1
>
>
> 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
[jira] Updated: (MNG-2805) Provide mechanism for suppressing
inherited/injected/mapped mojo binding
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
John Casey updated MNG-2805:
----------------------------
Fix Version/s: 2.1-alpha-1
> Provide mechanism for suppressing inherited/injected/mapped mojo binding
> ------------------------------------------------------------------------
>
> Key: MNG-2805
> URL: http://jira.codehaus.org/browse/MNG-2805
> Project: Maven 2
> Issue Type: New Feature
> Components: POM
> Affects Versions: 2.0.4
> Reporter: John Casey
> Fix For: 2.1-alpha-1
>
>
> 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
[jira] Commented: (MNG-2805) Provide mechanism for suppressing
inherited/injected/mapped mojo binding
Posted by "Aleksander Adamowski (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=199183#action_199183 ]
Aleksander Adamowski commented on MNG-2805:
-------------------------------------------
See also this thread: http://markmail.org/message/xbbmieckqt4ayd75
> Provide mechanism for suppressing inherited/injected/mapped mojo binding
> ------------------------------------------------------------------------
>
> Key: MNG-2805
> URL: http://jira.codehaus.org/browse/MNG-2805
> Project: Maven 2
> Issue Type: New Feature
> Components: POM
> Affects Versions: 2.0.4
> Reporter: John Casey
> Fix 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
[jira] Commented: (MNG-2805) Provide mechanism for suppressing
inherited/injected/mapped mojo binding
Posted by "John Casey (JIRA)" <ji...@codehaus.org>.
[ http://jira.codehaus.org/browse/MNG-2805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_121589 ]
John Casey commented on MNG-2805:
---------------------------------
See also: http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning
Foundational to this new feature.
> Provide mechanism for suppressing inherited/injected/mapped mojo binding
> ------------------------------------------------------------------------
>
> Key: MNG-2805
> URL: http://jira.codehaus.org/browse/MNG-2805
> Project: Maven 2
> Issue Type: New Feature
> Components: POM
> Affects Versions: 2.0.4
> Reporter: John Casey
> Fix For: 2.1
>
>
> 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
[jira] Commented: (MNG-2805) Provide mechanism for suppressing
inherited/injected/mapped mojo binding
Posted by "Ian Brandt (JIRA)" <ji...@codehaus.org>.
[ 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