Getting langtools into Maven Central
Jonathan Gibbons
jonathan.gibbons at oracle.com
Wed Dec 28 14:14:00 PST 2011
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
>
More information about the compiler-dev
mailing list