10

I've defined a Maven plugin with multiple goals. Currently users run my plugin as follows:

<plugin>
    <groupId>myGroupId</groupId>
    <artifactId>myArtifactId</artifactId>
    <version>someVersion</version>
    <executions>
        <execution>
            <goals>
                <goal>myGoal</goal>
            </goals>
        </execution>
    </executions>
</plugin>

but I've seen other plugins, like maven-compiler-plugin and Flyway, that don't require specifying an execution: https://flywaydb.org/getstarted/java

<plugin>
    <groupId>org.flywaydb</groupId>
    <artifactId>flyway-maven-plugin</artifactId>
    <version>5.2.4</version>
    <configuration>
        <url>jdbc:h2:file:./target/foobar</url>
        <user>sa</user>
        <locations>
            <location>classpath:db/migration</location>
        </locations>
    </configuration>
</plugin>

How do I specify the goal that should run by default when users exclude the <executions> block?

Gili
  • 86,244
  • 97
  • 390
  • 689
  • 1
    Look at the Flyway page more closely. The `pom.xml` is simply setting the required config. Further instructions all invoke mojos manually! I don't think I've seen a default execution except when supplied by a parent module (not directly from the plugin) – drekbour Aug 19 '20 at 11:57
  • 1
    goal usually have a "preferred" phase it will bind to. – SAURABH Aug 22 '20 at 11:45
  • 1
    I think the below link will help you. http://maven.40175.n5.nabble.com/Can-a-plugin-have-a-default-execution-goal-td108343.html – SAURABH Aug 22 '20 at 11:49

2 Answers2

5

AFAIK, there are not default goals for Maven plugins.

You can configure a plugin without adding a goal. But this does not execute the plugin.

The plugin must be either executed explicitly on command line (like flyway:migrate) or is executed automatically through the lifecycle (like compile:compile or jar:jar).

J Fabian Meier
  • 33,516
  • 10
  • 64
  • 142
  • Which strongly suggests stupidly hard-coded Executions config, inside Maven, for some core plugins, better defined as an optional default execution \@Mojo property flag for plugins with a declared "defaultPhase" \@Mojo property. – Infernoz Nov 27 '20 at 23:51
  • 1
    @Infernoz Default plugin executions are [defined by the packaging type](https://maven.apache.org/ref/3.8.2/maven-core/default-bindings.html#Plugin_bindings_for_jar_packaging). I think it makes sense to define it like this because you don't even need to declare the plugin to run – it wouldn't be possible to scan all plugins that exist to know which one needs to execute. Maven just does not support a default goal+phase per packaging type when you declare the plugin without those. – Didier L Aug 16 '21 at 12:45
0

I assume you are using the Java5 Annotations to mark your plugin as available mojo? (and not the javadoc way of living).

The @Mojo annotation has a defaultPhase attribute.

Once a user adds the plugin into the build these defaults (if set) will be used.

The Flyway Migrate Mojo does it this way too.

The compiler plugin is a bit of a bad example, as it is part of the default plugin bindings of the maven life-cycle itself. So the phase itself will know what mojo to run.

These are the docs for the maven plugin api, the one for using annotations is nearby.

If it is not your plugin, you can put the configs you want into a parent pom into the pluginManagement section.

wemu
  • 7,952
  • 4
  • 30
  • 59
  • 3
    I asked about a default goal and your answer talks about a default phase. My Mojo already has a default phase. I want Maven to execute a default goal if users include the plugin in their pom without an `` block. – Gili Jul 18 '19 at 22:51
  • I see. Sorry I got that wrong. My understanding is that only the plugins and goals in the life-cycle configuration don't need any more configuration (which comes via the packaging). Just adding a plugin (like the flyway maven plugin) into the build without an execution will do nothing yet. The defaultPhase attribute just saves that config from the execution in the pom. The goals you want to run still need to be specified. Even very common plugins like the failsafe plugin need to do this as they are not part of the default plugin bindings. – wemu Jul 19 '19 at 07:59
  • Options at this point may be creating your own packaging and default bindings or by creating an extension: https://maven.apache.org/guides/mini/guide-using-extensions.html – wemu Jul 19 '19 at 07:59
  • Does it make sense to use custom packaging for Maven modules? Would that even work. What would an extension allow me to do? I thought I need to output a custom artifact type (non-JAR) for that to work but in my case I am generating a Maven plugin so I'm not sure that would work... – Gili Jul 19 '19 at 16:11
  • every module can have its own packaging. I think you should be able to create a .jar file even with your custom packaging. But thats a rare thing. People might be confused. With an extension you can enhance the lifecycle: https://maven.apache.org/examples/maven-3-lifecycle-extensions.html - so probably enough to simplify plugin config. people would need to add the extension. also a rare thing to do. I think some executions and plugin config is perfectly acceptable for any maven plugin. – wemu Jul 19 '19 at 16:25