Gradle

  • Log In Access more options
    • Online Help
    • Keyboard Shortcuts
    • About JIRA
    • JIRA Credits
    • What’s New
  • Dashboards Access more options (Alt+d)
  • Projects Access more options (Alt+p)
  • Issues Access more options (Alt+i)
To raise new issues or bugs against Gradle, please use forums.gradle.org.
  • Gradle
  • GRADLE-1852

Tooling API: Allow custom jdk location definition for IntelliJ IDEA integration

  • Log In
  • Views
    • XML
    • Word
    • Printable

Details

  • Type: New Feature New Feature
  • Status: Resolved Resolved
  • Resolution: Duplicate
  • Affects Version/s: None
  • Fix Version/s: None

Description

The subj

Activity

Ascending order - Click to sort in descending order
  • All
  • Comments
  • History
  • Activity
  • TeamCity
  • Commits
  • Source
  • Reviews
Hide
Permalink
Kris De Volder added a comment - 17/Nov/11 11:25 AM

This is also important for STS/Eclipse integration. I have multiple reports of people having issues running Gralde tasks that require the Java compiler. Presumably the problems are due to gradle finding a JRE on their system and using that instead of the JDK.

There currently is no mechanism at all for the IDE to specify which JAVA_HOME gradle ought to use. So no way for me to really fix the problems those users are experiencing.

Blocked issues in STS:
https://issuetracker.springsource.com/browse/STS-2276
https://issuetracker.springsource.com/browse/STS-1756 (really an older duplicate of 2276)

Show
Kris De Volder added a comment - 17/Nov/11 11:25 AM This is also important for STS/Eclipse integration. I have multiple reports of people having issues running Gralde tasks that require the Java compiler. Presumably the problems are due to gradle finding a JRE on their system and using that instead of the JDK. There currently is no mechanism at all for the IDE to specify which JAVA_HOME gradle ought to use. So no way for me to really fix the problems those users are experiencing. Blocked issues in STS: https://issuetracker.springsource.com/browse/STS-2276 https://issuetracker.springsource.com/browse/STS-1756 (really an older duplicate of 2276)
Hide
Permalink
Szczepan Faber added a comment - 20/Nov/11 4:54 AM

I guess we need to take on GRADLE-1240 pretty soon.

Thanks for reporting!

Show
Szczepan Faber added a comment - 20/Nov/11 4:54 AM I guess we need to take on GRADLE-1240 pretty soon. Thanks for reporting!
Hide
Permalink
Szczepan Faber added a comment - 24/Apr/12 5:51 AM

Denis, I think this is a duplicate of GRADLE-1240. Pleas reopen if it is not. Cheers!

Show
Szczepan Faber added a comment - 24/Apr/12 5:51 AM Denis, I think this is a duplicate of GRADLE-1240. Pleas reopen if it is not. Cheers!
Hide
Permalink
Denis Zhdanov added a comment - 02/May/12 12:01 AM

Hi,

I don't see that the current task is a duplicate of GRADLE-1240. The current one asks an ability to define jdk to use by gradle (e.g. there are various java5, java6 and java7 versions available at the client's machine). The later talks about configuring jvm settings for the selected jdk.

Show
Denis Zhdanov added a comment - 02/May/12 12:01 AM Hi, I don't see that the current task is a duplicate of GRADLE-1240. The current one asks an ability to define jdk to use by gradle (e.g. there are various java5, java6 and java7 versions available at the client's machine). The later talks about configuring jvm settings for the selected jdk.
Hide
Permalink
Denis Zhdanov added a comment - 02/May/12 12:02 AM

Btw, it seems that I don't have enough rights at the tracker to reopen the ticket.

Show
Denis Zhdanov added a comment - 02/May/12 12:02 AM Btw, it seems that I don't have enough rights at the tracker to reopen the ticket.
Hide
Permalink
Kris De Volder added a comment - 02/May/12 11:38 AM - edited

I agree with Denis, calling it a duplicate may be stretching it.

However on the bright side. I do think this issue is now resolved. I even implemented something in STS already that allows the user to pick their JVM to use for Gradle. And I'm now able to pass this info to the tooling API with no problem.

The method in the API is this one:
org.gradle.tooling.LongRunningOperation.setJavaHome(File)

Show
Kris De Volder added a comment - 02/May/12 11:38 AM - edited I agree with Denis, calling it a duplicate may be stretching it. However on the bright side. I do think this issue is now resolved. I even implemented something in STS already that allows the user to pick their JVM to use for Gradle. And I'm now able to pass this info to the tooling API with no problem. The method in the API is this one: org.gradle.tooling.LongRunningOperation.setJavaHome(File)
Hide
Permalink
Szczepan Faber added a comment - 07/May/12 7:28 AM

Agreed, duplicate is a stretch. We always considered the args and java location as a same thing internally

Denis, did you notice the org.gradle.tooling.LongRunningOperation.setJavaHome(File) method? Does it solve the problem?

Show
Szczepan Faber added a comment - 07/May/12 7:28 AM Agreed, duplicate is a stretch. We always considered the args and java location as a same thing internally Denis, did you notice the org.gradle.tooling.LongRunningOperation.setJavaHome(File) method? Does it solve the problem?
Hide
Permalink
Denis Zhdanov added a comment - 09/May/12 1:21 AM

Yes, I think it addresses the problem.

Show
Denis Zhdanov added a comment - 09/May/12 1:21 AM Yes, I think it addresses the problem.

People

  • Assignee:
    Szczepan Faber
    Reporter:
    Denis Zhdanov
Vote (4)
Watch (5)

Dates

  • Created:
    20/Oct/11 12:34 AM
    Updated:
    04/Jan/13 5:10 AM
    Resolved:
    24/Apr/12 5:51 AM
  • Atlassian JIRA (v5.0.3#729-sha1:bf569e4)
  • Report a problem
  • Powered by a free Atlassian JIRA open source license for Gradle. Try JIRA - bug tracking software for your team.