Hi all,
the request for the skip-parameter started as a requirement to break an
infinite loop. When I discovered how the plugin was used and told that
binding the plugin to a different phase, the loop was gone. Even though,
the request for the skip parameter stayed.
I consider the javadoc:fix goal in the same range as the release:prepare
release:perform combination (why as is everything executed twice) and
cobertura-maven-plugin (why are the tests executed twice) and the fix-goal
is probably even worse.
You really must understand what this goal does under the hood. It calls
clirr:check, which always executes compile up front since it requires
compiled classes. if you bind javadoc:fix to the compile goal, you'll get
the infinite loop. Binding it to process-classes would fix this.
But from now on sources and classes are out of sync! This means that
plugins like maven-xref-plugin gives you wrong information.
So to be perfect, after executing javadoc:fix, one should recompile the
code.
But wait, now the sources in SCM are out of sync too. If you get an
exception and try to fix this based on the linenumbers in scm, you're
fooled. So it must be javadoc:fix + compiler:compile + scm:commit.
We can only force plugins to be executed up front, not afterwards (which
is probably a good thing).
It is impossible to come to one truth right now.
For this reason I'd go for activating the requiresDirectInvocation flag,
which means it cannot be used as part of the lifecycle anymore. (so yes,
we have control over how goals can be used). However, this will make the
plugin useless for persons like Richard.
So for me the impact of adding skip to the javadoc:fix goal is way too
big if it reflects uses as part of the lifecycle.
And as said: in this case the profile solution is fine.
regards,
Robert
ps. Adding the skip-parameter parameter to the AbstractMojo is not
possible unless every plugin adds the skip logic to its own execute()
method. Give it a try ;) We need to wait for Java8 runtime, where we can
add a default method for it to the Mojo interface.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
