Maven 2 & 3

Provide mechanism for suppressing inherited/injected/mapped mojo binding

Details

  • Type: New Feature New Feature
  • Status: Open Open
  • Priority: Major Major
  • Resolution: Unresolved
  • Affects Version/s: 2.0.4
  • Fix Version/s: Issues to be reviewed for 3.x
  • Component/s: POM
  • Labels:
    None
  • Complexity:
    Intermediate
  • Number of attachments :
    0

Description

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.

Issue Links

is duplicated by

New Feature - A new feature of the product, which has yet to be developed. MNG-3635 Provide a simple way to disable execution of an inherited plugin in child POM

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
John Casey added a comment -

See http://docs.codehaus.org/display/MAVEN/Suppression%2C+Ordering%2C+and+Replacement+of+Plugins+and+Mojos+Bindings for more info.

Show
John Casey added a comment - See http://docs.codehaus.org/display/MAVEN/Suppression%2C+Ordering%2C+and+Replacement+of+Plugins+and+Mojos+Bindings for more info.
Hide
Permalink
John Casey added a comment -

See also: http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning

Foundational to this new feature.

Show
John Casey added a comment - See also: http://docs.codehaus.org/display/MAVEN/Deterministic+Lifecycle+Planning Foundational to this new feature.
Hide
Permalink
Aleksander Adamowski added a comment -

See also this thread: http://markmail.org/message/xbbmieckqt4ayd75

Show
Aleksander Adamowski added a comment - See also this thread: http://markmail.org/message/xbbmieckqt4ayd75
Hide
Permalink
Ian Brandt added a comment -

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:

#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

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:

<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>

The <disableExecution> or <disablePlugin> additions proposed would certainly seem to offer a more straightforward and succinct solution.

Show
Ian Brandt added a comment - 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 : #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 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: <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> The <disableExecution> or <disablePlugin> additions proposed would certainly seem to offer a more straightforward and succinct solution.

People

  • Assignee:
    Unassigned
    Reporter:
    John Casey
Vote (8)
Watch (6)

Dates

  • Created:
    Updated: