I'm +1 with you on the fact that this code should be included after each javadoc goal.
I guess they agree too, but I *think* this is just something Olivier and the Maven PMC cannot afford integrating this code into the maven-javadoc-plugin without being 200% sure this isn't going to be a license infringement. This is their responsability not to drag the Apache foundation into such issues. Cheers 2013/6/20 sebb <seb...@gmail.com> > On 20 June 2013 13:21, Olivier Lamy <ol...@apache.org> wrote: > > 2013/6/20 sebb <seb...@gmail.com>: > >> On 20 June 2013 12:15, Olivier Lamy <ol...@apache.org> wrote: > >>> See https://github.com/olamy/JavadocUpdaterTool > >>> I added a maven build and a mojo. > >>> IANAL so I don't know if we can integrate the source of > >>> JavadocFixTool.java in javadoc plugin ( > >>> https://github.com/olamy/JavadocUpdaterTool/blob/master/LICENSE ) > >> > >> As far as I can tell, so long as the code is only used for the > >> intended purpose then it's OK. > >> > >> However, I don't think your plugin fixes all instances of bad javadoc; > >> certainly the instructions only solve the problem for site builds. > >> > >> What about javadoc jars? > > > > it simply depends the phase you bind the plugin (per default it's not > > bind to any phase) > > But the point is that a separate plugin will have to be separately > configured, probably several times. > > That's not a trivial job, and it's easy to overlook phases and > locations of Javadoc. > > Whereas if the Javadoc plugin fixes any issues before it completes, > the end user merely has to ensure they are using the new Javadoc > plugin. > That's much easier to do. > > >> > >> The Maven javadoc jar has lots of goals that occur in different > >> phases; the only way to be sure to fix all the issues is to always run > >> the tool after running Javadoc. > >> > >>> 2013/6/20 sebb <seb...@gmail.com>: > >>>> On 19 June 2013 22:40, Baptiste MATHUS <bmat...@batmat.net> wrote: > >>>>> Hi, > >>>>> I think the best way to track this is to file a JIRA ticket on > >>>>> http://jira.codehaus.org/browse/MJAVADOC > >>>> > >>>> Well OK, I can raise an enhancement request there too. > >>>> > >>>>> Btw, we might be interested by > >>>>> > https://github.com/AdoptOpenJDK/JavadocUpdaterTool/blob/master/src/main/java/JavadocFixTool.java > >>>> > >>>> That looks exactly like the file that was released by Oracle; anyone > >>>> can pick up the tool packaged as a jar from the Oracle web-site. > >>>> On it's own, it does not help. > >>>> > >>>>> Cheers > >>>>> > >>>>> > >>>>> > >>>>> 2013/6/19 sebb <seb...@gmail.com> > >>>>> > >>>>>> I expect you have all see the news about the Javadoc javascript bug. > >>>>>> > >>>>>> It's going to take a long time for everyone to update their Java > >>>>>> installations to Java 1.7 u25. Likewise for builds that need to use > >>>>>> other Java versions, tweaking poms so Java 7 is used for Javadocs > >>>>>> whilst still maintaining compatibility is a non-trivial task. > >>>>>> > >>>>>> Is there any interest in releasing a "quick-fix" version of the > >>>>>> javadoc plugin that automatically runs the tool after Javadoc > >>>>>> completes? > >>>>>> > >>>>>> The fix code is in Java, and can easily be directly called from the > >>>>>> plugin (no need to start a new process). > >>>>>> > >>>>>> The license looks friendly so long as the code is only used for > >>>>>> Javadoc fixups, and changes are allowed, which is just as well - > >>>>>> > >>>>>> There are a couple of bugs in the tool as currently released. > >>>>>> It does not close all the resources; and failure to close the input > >>>>>> file means it cannot delete the original input file on Windows; that > >>>>>> needs to be fixed as it would not make sense to keep the old faulty > >>>>>> file (even if it is now called index.html.orig). > >>>>>> > >>>>>> I can provide details of the fixes, but a decent IDE will probably > >>>>>> warn about them anyway. > >>>>>> > >>>>>> It would be a great service to the Java community if this could be > >>>>>> fast-tracked. > >>>>>> > >>>>>> > --------------------------------------------------------------------- > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>> -- > >>>>> Baptiste <Batmat> MATHUS - http://batmat.net > >>>>> Sauvez un arbre, > >>>>> Mangez un castor ! > >>>> > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>> > >>> > >>> > >>> > >>> -- > >>> Olivier Lamy > >>> Ecetera: http://ecetera.com.au > >>> http://twitter.com/olamy | http://linkedin.com/in/olamy > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > > > > > -- > > Olivier Lamy > > Ecetera: http://ecetera.com.au > > http://twitter.com/olamy | http://linkedin.com/in/olamy > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > > -- Baptiste <Batmat> MATHUS - http://batmat.net Sauvez un arbre, Mangez un castor !
