Getting langtools into Maven Central

[Jesse Glick]

Since official releases of langtools are now available under a permissive license, has any thought been given to getting it published on Maven Central for various uses?

1. Programs running on JDK 5, or Java 6+ JRE, should be able to use JSR 199/269 just by declaring a dependency on it.

2. Projects should be able to able to use these APIs in unit tests, e.g. to compile code snippets, without fear that tools.jar will not be in the test classpath. 
Currently you have to use a system-scope hack [1] which is not portable and can cause fatal errors dealing with released POMs if you are not careful (e.g. follow the 
recommended idiom, which broke due to the Oracle acquisition [2]).

3. Projects may wish to compile sources using a specific version of javac [3], especially if they use exotic generics features and so on; some builds of javac contain 
known bugs that were later fixed, but you cannot rely on every developer checking out your project to have the latest update installed. Would be great to have a 
plexus-compiler-api plugin [4] using JSR 199, where the langtools release could be overridden via <plugin>/<dependencies>.

I did a quick search for existing artifacts; besides JSR 308, the only one I could find is sorcerer-javac [5], which is from an old snapshot 
(compiler-7-ea-src-b12-06_may_2007.zip).

It would be great to get langtools from OpenJDK 7 (using -target 5) published on Maven Central, probably via OSSRH [6]. For maximum flexibility it could be split into 
several artifacts, with logical interdependencies (deps on #1 would be marked <optional> since Java 6+ users do not necessarily want them separately):

1. javax.annotation.processing + javax.lang.model + javax.tools
2. com.sun.source >#1
3. com.sun.tools.javac >#2
4+ javadoc, javap, javah, doclets, apt...?

or more simply into javax.** vs. com.sun.** artifacts.

Publishing regular updates would ideally require Ant targets to build the requisite JARs (binary, sources, javadoc) and deploy them to the staging server, which I guess 
you mean a patch to make/build.xml. Some mapping from OpenJDK Hg tags (jdk7u2-b13) or printed versions (1.7.0_02) to standard-format Maven versions like 7.0.2 might be 
necessary to make comparisons happy.

Does this sound like a good direction to take? If so, I could try to set up OSSRH for the project and supply a patch for the build script, though it would be best for 
organizational reasons if an OpenJDK committer working on langtools did the actual publishing on an ongoing basis.


[1] http://maven.apache.org/general.html#tools-jar-dependency
[2] http://java.net/projects/sezpoz/sources/svn/revision/156
[3] https://jira.codehaus.org/browse/MNG-1867?focusedCommentId=231831&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-231831
[4] http://plexus.codehaus.org/plexus-components/plexus-compiler/plexus-compiler-api/apidocs/index.html
[5] http://search.maven.org/#artifactdetails%7Corg.jvnet.sorcerer%7Csorcerer-javac%7C0.8%7Cjar
[6] https://docs.sonatype.org/display/Repository/Sonatype+OSS+Maven+Repository+Usage+Guide