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.
Untrue. I opened MJAVADOC-451 first. It was the first time I'd submitted
anything from the Maven community. I hadn't even found the looping
behavior yet. The point was that the looping behavior was trivial to fix
because I had *already* added the skip.
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.
javadoc:fix with force=true is akin to running the checkstyle plugin but
having it actually fixing the formatting in band. But - this behavior
requires force=true. You accidentally stumble on this behavior.
So forget about force=true for a moment. What if I simply want to force
ALL of my developers, because they are so lazy about entering proper
javadocs, to have the fix goal executed interactively? But I want them
to be able to explicitly skip it, or for the CI servers to skip it?
The point is, there are many ways that people can find to use the
capabilities of a given plugin.
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.
Here is one point I agree with you - *if* this goal must NEVER be
allowed to run in the lifecycle, then the skip parameter makes no sense,
and requiresDirectInvocation should be set to true.
But remember the goal already has the force=true option. Its not like
people can accidentally introduce this without giving some thought to
what they are doing.
So in the end I think you are simply taking away a potentially useful
option. I totally understand the risks of having the local files
changing and the line numbers not lining up to what is in SCM. But I've
decided, the way my team operates, that I accept that risk, and I am
otherwise getting a good value out of this plugin. So I would be
disappointed if the plugin changed to requireDirectInvocation. We could
add an additional INFO message when using the goal with force=true
saying "Hey we're about to automatically scan through and potentially
change your code!"
I think everyone on the list agrees that a skip parameter is good *if*
the plugin remains as it is and can be executed as part of the
lifecycle. So I'm pushing for a decision here:
1) add the skip option (and potentially a stronger warning message on
force=true as well)
or
2) set requireDirectInvocation to true
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.
Agreed, I was thinking the same thing about java8 and the Mojo
interface. Maven 4.0?
Best regards,
Richard
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
