[
https://jira.codehaus.org/browse/MPLUGIN-243?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=336711#comment-336711
]
Robert Scholte commented on MPLUGIN-243:
----------------------------------------
IMO this is the wrong approach. Such situations happen with bad designs of
plugins. There's probably some shared code + parameters and the lazy solution
is to pull it up to a shared Mojo, even though some subclassing mojo's don't
need it.
Instead I'm thinking about some kind of injectable mojo, a special kind of
{{Component}}.
{code}
@InjectableMojo
private UnpackMojo unpackMojo;
{code}
Instead of calling methods of the superclass, you would call methods on this
mojo. The maven-plugin-plugin should generate a descriptor with its own
parameters and those of the injectable mojos.
I haven't fully thought of all the implications, but this looks more like the
right approach to me.
> add an option to hide a mojo parameter from generated documentation
> -------------------------------------------------------------------
>
> Key: MPLUGIN-243
> URL: https://jira.codehaus.org/browse/MPLUGIN-243
> Project: Maven Plugin Tools
> Issue Type: Improvement
> Components: maven-plugin-annotations,
> maven-plugin-tools-annotations, maven-plugin-tools-java,
> maven-plugin-tools-javadoc
> Affects Versions: 3.2
> Reporter: Herve Boutemy
> Priority: Minor
> Fix For: 3.3
>
>
> when a parameter is defined in a parent mojo, because it needs to be shared
> by some child mojos, but some other child mojos don't use the feature,
> parameter documentation just adds unnecessary complexity
> see MDEP-413 for such an example
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
