Toyed with it a long time ago. It's a great concept for anyone that publishes their javadoc APIs to third party consumers.
For the non-Java-optimized builds I was considering wedging it into at the time, there was no easy way to generate the comprehensive javadoc for an entire product, much less attempt to run javadoc against two different instances of the source tree. We did not have to publish any APIs to anyone except other developers that had direct access to the source code repositories, so using the built-in diff capabilities there remained sufficient for code reviews. It still would have been nice to have for the higher-level change view it provides, but not enough to try and work around the build constraints at the time. I thought jdiff was almost a dead project, but just noticed that there is an active beta of the maven-jdiff-plugin for maven 2. The maven-1 plug-in development halted in 2007. Gradle _might_ be able to benefit from this, but to my knowledge, it's only going to catch Java code changes, not groovy or the custom DSL generated documentation. Most people that are using Gradle aren't directly going to the Javadocs, but rather to the User's Guide and the DSL reference guide. I could see it as being part of a larger API difference solution, but not sure if the cost/benefit ratio is a clear win for Gradle. -Spencer >________________________________ > From: Luke Daley <[email protected]> >To: [email protected] >Sent: Thursday, June 14, 2012 7:57 AM >Subject: [gradle-dev] JDiff. > >Just stumbled across http://www.jdiff.org/ > >Have only just read the site. > >Does anyone have experience with it? > >-- >Luke Daley >Principal Engineer, Gradleware >http://gradleware.com > > >--------------------------------------------------------------------- >To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > > >
