|
What a bizarre icon showed up! I didn't mean to make a warning sign in the above comment; sorry. I typed an exclamation point in parentheses... Here is a proposed patch. Is it enough for your use case? I don't have exactly a test case, but I can attach the pom that we had to make to make things work, as you can see there is a profile that activates the usage of the special doclet and reconfigures the javadoc plugin accordinly (see the javadoc config in build and then the "uml" profile near the end). If not already done, could you try the patch and give us your comments? The patch looks OK, but is there any reason that validateStandardDocletOptions() is not called if a custom doclet is specified with useStandardDocletOptions? The workaround for this issue is to specify all options in <additionalparam>: which is painful. I'd love to see this patch applied to the next release. Fixed in r680869 |
||||||||||||||||||||||||||||||||||||||||||||
I would add that I also think this is needed. Another reason is that you may actually specify what is the default doclet, but the mere presence of the doclet element blocks the default parameters from being used. Such a configuration was useful when recently the javadoc plugin did not use the default doclet behavior by default; and if you wanted the default output provided by your JDK then you had to explicitly specify it – and then these swithces were not passed to the doclet. Note that I actually don't know what Maven is now using as the default doclet since I haven't actually checked into it, but it now at least appears to be the default one – there is a new color scheme since 5.0 that now is being used in Maven's output.
The suggestion noted above sounds great. Frankly though, simply always passing whatever has been declared sounds fine to me, even if an exception results, since this should be expected by anyone declaring these attributes alongside one another. Exceptions are always acceptable.