Is there any thought on easing managing a site for multiple versions of a component. Right now, for some components, we have >1 Javadoc site. It would be nice to at least automate that. But why not have the whole site?
https://commons.apache.org/proper/commons-lang/2.6 https://commons.apache.org/proper/commons-lang/3.0 https://commons.apache.org/proper/commons-lang/3.1 https://commons.apache.org/proper/commons-lang/ would give a list of available versions. Gary On Wed, Jun 19, 2013 at 7:44 PM, sebb <seb...@gmail.com> wrote: > I've been developing some Maven plugins in the Sandbox, and I now > propose to move them to Commons proper. > > commons-javadocfix-plugin > ==================== > Runs the Oracle JavadocFixTool as a Maven plugin or a Java > command-line application. > The tool was released by Oracle recently in order to fix up Javadoc > files that have some javascript which is vulnerable to attack. > The original Oracle tool has some bugs (e.g. did not delete temporary > saved copy of original file on Windows) which have been fixed. > > Ideally the Maven aspect would be fixed by an update to the Maven > Javadoc plugin, but that might take a while to implement. > I've raised http://jira.codehaus.org/browse/MJAVADOC-370 > > In the meantime it might be necessary to use it to implement the > fuctionality ourselves. > > commons-digest-plugin > ================= > This is a simple plugin that generates MD5 and SHA1 hashes for files > in a directory. > This is intended for use in simplifying the deployment of tarballs > (source and binary packages). > > commons-gpg-plugin > =============== > Like the Digest plugin, but creates sigs for files in a directory. > The Maven version of the plugin cannot sign arbitrary files, but I've > raised an enancement request to add this functionality, so hopefully > the Commons plugin won't be needed for too long. > > commons-staging-plugin > ================== > This handles the rest of the functions needed to deploy tarballs > separately from Nexus. > The main functions are upload of tarballs to the dist/dev directory > and later release by moving the tarballs from dist/dev to dist/release > > I'm not entirely happy with the name "Staging", as it is only part of > the function. The name can be changed if necessary. > > I intend to move the plugins tomorrow sometime unless there are any > objections. > > The next stage will be to get some people to test them to see if they > need to be improved, and then hopefully release them so they can start > being used. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > > -- E-Mail: garydgreg...@gmail.com | ggreg...@apache.org Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
