Sorry for asking so many questions, but I am now confused.  When you
say "You must bind your mojo to a specific phase", where does this
binding happen?  Inside the pom associated with the mojo or inside the
plugin consumer's pom?  Earlier, I think you implied that this had to
happen in the consumer's pom, but is that not what you are saying now?
 If this is the correct interpretation, can you point me to some docs
or an example of how to do this?

My goal is to do all of the configuring inside of the mojo's pom so
that the plugin consumer has to do as little configuring as possible
(preferably none at all, except for declaring a dependency).

thanks,
Andrew

On Wed, Nov 30, 2011 at 2:26 PM, Jeff MAURY <jeffma...@jeffmaury.com> wrote:
> No, you can have a mojo automatically invoked as soon as it is declared in
> a pom. You must bind your mojo to a specific phase.
>
> Regards
> Jeff MAURY
>
> On Wed, Nov 30, 2011 at 10:48 PM, Andrew Eisenberg <
> andrew.eisenb...@gmail.com> wrote:
>
>> On Wed, Nov 30, 2011 at 1:31 PM, Jeff MAURY <jeffma...@jeffmaury.com>
>> wrote:
>> > You can develop a Mojo that will do the trick but you will have to
>> > configure it in you pom (at least define it so that it will be invoked)
>> so
>> > I don't see the added value compared to the build-helper-plugin
>>
>> Right. Well, the only benefit is that doing it through the mojo that I
>> would create is about 6 fewer lines of configuration, which is not
>> much benefit (and I actually did get this working, but I wasn't happy
>> with the solution).  I must say that I am disappointed in maven that
>> this is not possible.  I was expecting that mojos could somehow be
>> executed implicitly just by referencing a plugin in your pom.  I'm
>> sure there's a reason for not allowing this, but from my perspective
>> allowing this would certainly cut down on some configuration
>> verbosity.
>>
>> Thanks for your help with this.  I'll have to settle for the
>> build-helper-maven-plugin approach.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
>> For additional commands, e-mail: users-h...@maven.apache.org
>>
>>
>
>
> --
> "Legacy code" often differs from its suggested alternative by actually
> working and scaling.
>  - Bjarne Stroustrup
>
> http://www.jeffmaury.com
> http://riadiscuss.jeffmaury.com
> http://www.twitter.com/jeffmaury

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@maven.apache.org
For additional commands, e-mail: users-h...@maven.apache.org

Reply via email to