I will JIRA a request to make the AbstractCompilerMojo into a component.
On Mon, Mar 24, 2008 at 10:12 AM, Stuart McCulloch <
[EMAIL PROTECTED]> wrote:
> On 24/03/2008, Benson Margulies <[EMAIL PROTECTED]> wrote:
> >
> > Ah. So one might imagine someone refactoring things so that all the
> > injected
> > fields of AbstractCompilerMojo were protected, so that an extending
> class
> > in
> > another plugin could have parallel annotations.
> >
>
> while that might look ok at first glance, I can tell you from experience
> that it doesn't work well in practice - sure if the base class fields were
> protected (or there were setters) then you could add your own local
> plexus/javadoc tags and push any injected values back into the base
> ... however, there are several major drawbacks to this approach:
>
> 1) you're duplicating tags - the base class tags may change
> in the future, which makes this a maintenance nightmare
>
> 2) currently mojo parameters have to be attached to a declared
> field (and usually derive their values from the name), so you'd
> either need to alias them, or use the same name as the fields
> in the base class - but this means you'd hide the original field:
>
> class Base { /** @parameter */ protected String foo; }
>
> class A extends Base { /** @parameter */ protected String foo; }
>
> A's foo is different to Base's foo (different declaring class)
> and you can't always guarantee which one will get injected
>
> currently the best way to share functionality between mojos is to push
> the shared code into a component, which is then properly injected by
> plexus when it's used in each mojo, for examples see:
>
> https://svn.apache.org/repos/asf/maven/shared/tags
>
> imho the second best approach is merging the plugin.xml (as done by
> the maven-inherit-plugin) - this avoids having to duplicate/hide fields
>
> the last approach is to make a local branch of the plugin project, which
> means you have the source of the base class available at compile-time
>
> these are the only viable solutions I've found with the current injection
> approach - of course if Java5 annotations were used then the details
> could be kept at runtime, but this would mandate the use of Java5 and
> mean several changes to the plexus container system...
>
> --
> Cheers, Stuart
>
