[GRADLE-2251] Projects using only 'java-base' plugin get an empty classpath in tooling API Created: 24/Apr/12  Updated: 10/Feb/17  Resolved: 10/Feb/17

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: None

Type: Bug
Reporter: Kris De Volder Assignee: Unassigned
Resolution: Won't Fix Votes: 0


I am trying to setup something that lets users more easily create new Gradle projects in STS.
To this end I allow the user to create a new project containing one of the sample projects from RC1 distribution.

When using the samples/java/base sample project however, the resulting project has compile errors.
The reason for this problem appears to be that the classpath for this sample project as returned by the tooling API contains no entries.

When I modify the sample project to

apply plugin: 'java'

instead of

apply plugin: 'java-base'

Then the classpath is populated properly.

I'm not sure how serious a problem this is. I imagine most people will use 'java' plugin rather than just 'java-base' so are not likely to hit this problem.

Perhaps the most serious problem here, is that a sample project bundled with the official gradle distribution does not import/work correctly in the IDE.

Comment by Szczepan Faber [ 30/Apr/12 ]

Hey Kris,

'java-base' plugin will never work as conveniently as the 'java' plugin. For example, java-base does not declare 'main' or 'test' sourceSets. So, in order to have the sources/classpath configured correctly, the tooling API user would have to add extra eclipse configuration in his builds to make the tooling api experience seamless.

I don't like our javaBase sample and I'll do some refactorings so that users will not fall into the 'java-base' + IDE trap.

Thanks for reporting!

Comment by Radim Kubacki [ 19/Feb/14 ]

This can be addressed if we expose Java components more directly in Tooling API and let the IDEs to handle them. OTOH there is also risk of conflicts: android plugin applied 'java-base' and if we start to build Idea and Eclipse models from 'java-base' it can break Android projects.

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 12:16:50 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.