[GRADLE-1477] Support adding tools.jar to dependencies Created: 16/Apr/11  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: 1.0-milestone-2
Fix Version/s: None

Type: New Feature
Reporter: Marco Hunsicker Assignee: Unassigned
Resolution: Won't Fix Votes: 11

Attachments: Zip Archive gradle-issue.zip    


It would be nice if Gradle could natively support adding tools.jar (classes.jar on Mac OS X).

Either expand the logic behind org.gradle.api.tasks.compile.CompileOptions#includeJavaRuntime or add a new property to control this specific behavior.

I saw that some comments on the mailing-list regarding this topic, but could not find a JIRA on this.

Comment by Marco Hunsicker [ 19/Apr/11 ]

I just tested on Mac OS X and here the automatic inclusion of classes.jar seems to work. It's therefore probably a bug that it doesn't on Linux (Ubuntu 10.04 64bit, Oracle 1.6.0_24-b07)

Comment by Marco Hunsicker [ 19/Apr/11 ]

Demo project to demonstrate the problem.

$ gradle compileJava

fails to compile the source file under Ubuntu. Uncommenting the dependency makes it work. Seems to work out-of-the-box on Mac OS X

Comment by Enrique Zamudio López [ 05/Oct/11 ]

I ran into this problem indirectly when trying to use Lombok in a mixed Java-Groovy project; groovyc can't seem to use Lombok as an annotation processor on Linux, even though pure Java projects can use Lombok without any problems (also the classes in src/main/java which use Lombok inside a Groovy project compile fine).

EDIT: I managed to work around this by not forking the groovy compiler with the line:


Now it works both on OSX and Linux.

Comment by Klaus Lehner [ 11/Feb/12 ]

We are currently trying to migrate http://asdoclet.fluffnstuff.org/ to gradle and can't because that framework uses the JavaDoc classes inside tools.jar a lot, so that issue here is a show-stopper for us.

Comment by Peter Niederwieser [ 12/Feb/12 ]

@Marco: Mac OS has no tools.jar, it is included automatically.

@Klaus: You can add tools.jar yourself, with something like:

dependencies {
  compile files("${System.getProperty('java.home')}/lib/tools.jar")
Comment by Marco Hunsicker [ 12/Feb/12 ]

On Mac OS X 'tools.jar' is named 'classes.jar', and it is indeed included automatically. But it is Ubuntu where the default behavior fails me as the attached example tries to demonstrate.

Against which Gradle version(s) did you try the sample project? Thanks.

Comment by Peter Niederwieser [ 12/Feb/12 ]

I didn't try the sample project. Did you try to add the tools Jar as shown above?

Comment by Marco Hunsicker [ 13/Feb/12 ]

I only reported this issue, because my project did not build without custom changes. I did not rate this problem as a show-shopper. I've used similar code like you as a workaround.

I for one would appreciate if building on Linux would work just like on other platforms - without having to apply custom code. 'includeJavaRuntime' simply did not work as advertised. I haven't tested with the most recent milestones. Thanks.

Comment by Steve Ebersole [ 20/Mar/12 ]

Peter, for what its worth we just ran into this for the Hibernate build and what you suggested worked for us. The build was running on Mac OS, this got it running on Linux, no idea about Windows.

Comment by Nathan [ 28/May/15 ]

So I'm encountering a slightly related issue.

I'm using a 3rd party library that creates a JavaDoc/Doclet so it needs `tools.jar`.

However, the library source uses Java 7's JavaDoc API. The JavaDoc API was changed in Java 8. I have Java 8 installed on my system.

When I use the following in my `build.gradle` file:
compile files("${System.properties['java.home']}/../lib/tools.jar")

This is the path it resolves to:

which then causes a compilation error due to mismatched APIs.

Is there any way to handle this situation? The only way I can think of overcoming it is to manually copy the `tools.jar` Java 7 Version into a `lib` folder and just include it with:
fileTree(dir: 'lib', include: '*.jar')

Comment by Benjamin Muschko [ 15/Nov/16 ]

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

  • Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
  • Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Comment by Benjamin Muschko [ 10/Feb/17 ]

Thanks again for reporting this issue. We haven't heard back from you after our inquiry from November 15th. We are closing this issue now. Please create an issue on GitHub if you still feel passionate about getting it resolved.

Generated at Wed Jun 30 11:56:30 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.