I'd rather have a solution that wasn't specific to compilation. Instead, I think we should have the compile classpath end up with artefacts that contain only the API classes of each dependency. We'll need to do this anyway in the compiler implementation, as the Java compiler does not use a ClassLoader to resolve classes.

This way, we can reuse the API-implementation separation for work other than compiling in Gradle. For example, only the API classes would be added to the IDE compile classpath (for those IDEs that support it). API documentation and static analysis would consider only API classes (making up-to-date checks faster).

And, we can reuse the API-implementation separation for components other than OSGi. For example, for a Gradle-built java library, we can publish the API definition and use it in the consumer to build an API jar for use in the compile classpath.

How is this issue different to GRADLE-2236?

It was a duplicate. I deleted 2236.

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!

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.