maven-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen Connolly <stephen.alan.conno...@gmail.com>
Subject Re: Call a custom plugin from another project
Date Wed, 05 Jun 2013 10:06:34 GMT
Maven has a couple of default packaging types that have defined lifecycles.

e.g. `jar`, `war`, `ear`, etc.

If you don't specify `<packaging>` then Maven assumes that your project is
`<packaging>jar</packaging>` by default.

Maven will then consult its registry of lifecycles and see the lifecycle
for the `jar` (or whatever packaging you specified - assuming it exists)
and based on that lifecycle it will add the plugin executions defined by
the lifecycle.

So, for example, if you don't specify a `<packaging>` then the `jar`
lifecycle will be assumes, and the `jar` lifecycle binds `jar:jar` to the
`package` phase.

So you have (at first look) three choices:
1. Get your plugin goals added to the default lifecycle(s) in the
appropriate phases
2. Define a custom lifecycle (with a corresponding custom packaging type)
3. Put up with having to define `<executions>` in the `pom.xml`

Now, #1 is *never* going to happen for 99.99999999999999% of plugins. As
that would push your plugin executions onto *every* Maven user. Changing
the default lifecycles is not something we do on a whim. So let's cross
that off your list of options.

#3 is the one you are trying to avoid, so that leaves #2.

How will #2 look?

Well as you are defining a custom lifecycle, you will need to tell Maven
about this custom packaging type. To do that you have to register the
custom packaging type with Maven. This will require EITHER adding
`<extensions>true</extensions>` to the `<plugin>` section in the `pom.xml`
using your custom packaging OR adding a `<extension>` to the `<build>`
section.

So, what I am saying is that there is no way you can have your plugin
*magically* executed against a project which has not been informed of your
plugins existence in some way or other... you will either have

<project>
  ...
  <build>
    ...
    <plugins>
      ...
      <plugin>
        <groupId>your-group-id</groupId>
        <artifactId>your-maven-plugin</artifactId>
        <version>x.y.z</version>
        ...
        <executions>
          <!-- some configuration goes here -->
        </executions>
        ...
      </plugin>
      ...
    </plugins>
    ...
  </build>
  ...
</project>

or you will have

<project>
  ...
  <packaging>your-packaging</packaging>
  ...
  <build>
    ...
    <plugins>
      ...
      <plugin>
        <groupId>your-group-id</groupId>
        <artifactId>your-maven-plugin</artifactId>
        <version>x.y.z</version>
        ...
        <extensions>true</extensions>
        ...
      </plugin>
      ...
    </plugins>
    ...
  </build>
  ...
</project>

or you will have

<project>
  ...
  <packaging>your-packaging</packaging>
  ...
  <build>
    ...
    <extensions>
      ...
      <extension>
        <groupId>your-group-id</groupId>
        <artifactId>your-packaging-definition</artifactId>
        <version>x.y.z</version>
      </extension>
      ...
    </extensions>
    ...
  </build>
  ...
</project>

Note: you could have the extensions registered in the parent (works for
either the /project/build/plugins/plugin/extensions route or the
/project/build/extensions/extension route), which might simplify things if
you are building multiple modules of the same packaging.

So it is really a question of picking which is the least pain. See
http://developer-blog.cloudbees.com/2013/04/the-maven-way.html for some
hints as to the end-game direction you want to head towards.

Finally, the `<execution>` section does not have to be too bad. If you
specify a default phase when you define your mojo, you can usually get away
with just

<execution>
  <goals>
    <goal>my-goal</goal>
  </goals>
</execution>

or if you have multiple goals with different default phases, you can have

<execution>
  <goals>
    <goal>my-goal</goal>
    <goal>my-other-goal</goal>
  </goals>
</execution>

And they will execute against their respective default phases... you only
need multiple `<execution>` sections with their own `<id>` for the case
where you want to override / have to specify the `<phase>`

HTH

-Stephen

On 5 June 2013 10:23, alesky <alessandro.dottavio@gmail.com> wrote:

> what i want to do is to force to execute my plugin
> in a specific phase
> with a specific goal (my plugin will have only one goal)
> without declare it
> i mean that i don't want that the user declare the <execution> tag
>
> as for example i use the jar-plugin
>
>
>
>
>
>
>
> --
> View this message in context:
> http://maven.40175.n5.nabble.com/Call-a-custom-plugin-from-another-project-tp5758214p5758280.html
> Sent from the Maven - Users mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message