Getting langtools into Maven Central

[Jonathan Gibbons]

It may be appropriate to do this for OpenJDK 6 and 7, but it is probably 
not appropriate for pre-release builds of 8.

JSR 199 and JSR 269 are not available on JDK 5.

-- Jon

On 12/28/2011 08:45 PM, Jesse Glick wrote:
> 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
>