tool (mojo) lifecycle

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

tool (mojo) lifecycle

Jason Nerothin
I'm working in a multi-module system and want to provide a mojo that can be
inserted in to the process-resources and process-test-resources phases. I'm
wondering how to handle the lifecycle of the tool itself?

I've written other mojos in the past that live in the project itself, but
I'm not sure that's appropriate.

[proj]
  [tools]
    [mojo1]
  [module1]
    <dependency>...<artifactId>mojo1</artifactId><version>[proj's
version]</version></dependency>
  [module2]
  ...

I feel like it may be better to stick it out in a separate repository so
that the lifecycle of the tool and project are decoupled.
Reply | Threaded
Open this post in threaded view
|

Re: tool (mojo) lifecycle

Wayne Fay
> I feel like it may be better to stick it out in a separate repository so
> that the lifecycle of the tool and project are decoupled.

I agree. This is nearly always the right approach.

Wayne
Reply | Threaded
Open this post in threaded view
|

Re: tool (mojo) lifecycle

Kathryn Huxtable
I assume you mean "artifact" instead of "repository"? -K

On Sep 4, 2011, at 12:05 AM, Wayne Fay wrote:

>> I feel like it may be better to stick it out in a separate repository so
>> that the lifecycle of the tool and project are decoupled.
>
> I agree. This is nearly always the right approach.
>
> Wayne


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]