The public API is what's documented in the [Javadoc]([1]http://www.gradle.org/docs/current/ja...) and [Groovydoc]([2]http://www.gradle.org/docs/current/gr...). Everything else (including `GUtil`) is private.
----------------------------------------------------------------------------------------
[1] http://www.gradle.org/docs/current/javadoc/
[2] http://www.gradle.org/docs/current/groovydoc/

Does that mean that plugin authors have to reinvent everything afresh? Eg. DefaultSourceDirectorySet and the like?

If you want to be on the safe side, yes. There should probably be some API for adding source directory sets, but currently there isn't.

This is really painful. May I include parts of the gradle source in a MIT licensed plugin project? To get a local DefaultSourceDirectorySet for example. Or does Apache conflict with MIT or vice versa?

Hint: Implement all plugins using only the public plugin API.

MIT and Apache are both very permissive licenses, but I don't know the answer to your question.

Then I will take the usual approach: include a copy of the DefaultDirectorySet and dependencies, document the fact clearly in code and README, and wait till someone sues me.

But to be honest: I don't think this is a solution. In particular central concepts like source sets should not depend on custom implementations by random plugin authors.

You shouldn't need to implement `SourceSet`. Instead, you can (and should) use the `SourceSetContainer.add()` factory method.As I said, there should probably be a similar factory method for source directory sets. It's much less common to add your own source directory sets than it is to add your own source sets, but nevertheless it would be good to support it in the public API.

I need a SourceDirectorySet, because I need the source directories for the clojure part. Those have to be on the classpath for compilation to work.

On the other hand I want to provide methods "includeNamespaces" resp. "excludeNamespaces" which would act like include or exclude but on clojure namespaces names. The namespace pattern are then translated to the corresponding file patterns. So I have to provide my own ClojureSourceSet which delegates under the covers to a SourceDirectorySet which was up to now a DefaultSourceDirectorySet.

The groovy plugin does something similar.

If there was a way to add source directory sets like there is for source sets, you would get the delegation for free, and it wouldn't be necessary to implement your own source set. To add additional methods, you can use an extension object. The `DefaultSourceSet` and `DefaultDirectorySourceSet` classes will likely stay private.

I think that is already going on: I use a convention object to add methods to the source set. So the new clojure method will return the clojure SourceDirectorySet, the excludeNamespaces method is added, etc. Nonetheless I have to create a SourceDirectorySet at some point.

If there is a just a factory method missing...

Plugin authors should have an easy way to add new source directory sets (e.g. clojure) to source sets. Currently it is necessary for the plugin author to add a convention object to the source set and to either implement SourceDirectorySet or use Gradle's internal implementation class. Maybe SourceSet could be a DomainObjectContainer<SourceDirectorySet>.

Faced this right now trying to carefully re-implement support for Kotlin (http://confluence.jetbrains.com/display/Kotlin) in Gradle

A source set redesign is underway for inclusion in Gradle 1.5. Of course the old APIs will stay, at least until Gradle 2.0.

Glad to hear that. Thank you!

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.