Hello all, as it’s my first post on this list, some context: I’m the lead for the Android dev tools at Google and I’m working on our new build system based on Gradle. I’ve worked with Adam and Hans in the last few months to get the project started.
We have a concept of build variants in our plugin which allow a project to build different versions of the same app (either different flavor of it, or different builds of it -- debug vs release for instance). Each variants has its own source sets, it own dependencies and its own output. One additional complication: some of the source sets could be used by multiple variants. IDE integration is critical to us and we need to make sure that the Tooling APIs can surface this to the IDEs. The idea is that the developer would choose which variant to work on, thus enabling a specific set of source sets in the IDE, setting up the current classpath, and selecting the proper output to run when requested. Additionally, we’d like to have other plugins be able to act on Android projects. For instance the FindBugs plugin would have to be able to know what sourcesets to use together, where the compilation output is, etc... I’d like to propose that Gradle adds native support for build variants, and that plugins should be able to “register” variants (our variants are automatically created from items defined in the build.gradle file), and the API should let other plugins (and the IDE) query for variants and their configuration (dependencies, source sets, output, etc...) I think the biggest challenge is handling sourcesets. The current Java SourceSet is very specific to the Java plugin and includes not only the source but also the output. Also, creating a SourceSet automatically creates a set of tasks to compile this SourceSet, which was not good for us. Unfortunately, this is what most other plugins rely on, querying Java sourcesets and their output (for instance the STS plugin does this, I’m sure the FindBug plugin does this as well). In our case we have our plugin do things a bit differently. We don’t use the normal SourceSet and have rolled up our own to decouple the output from the source and not create tasks we don’t need. Instead we create our own JavaCompile tasks and wire the input and output manually based on the current variant and its sourcesets. We’d like to see if we can separate the notion of source folders from the output (and the creation of the tasks). On top of Java we also have JNI code as well as other languages (that are specific to Android). I’m not sure if we are going to use the CppSourceSet just yet as we are likely to simply call out to our make-based build system for those for now. In general though, we’d like to make sure the tooling API is flexible and that the concept of SourceSet is abstract enough so that we can use our own, while still benefiting from the ecosystem of Gradle plugins (Disclaimer: I’m not super familiar with the Tooling API yet) We are starting to look at IDE integration, and there are a lot of changes to make there, but we’re going to need these changes in Gradle to be able to make progress on the IDE side. I realize this is a lot of work there. Adam and I already talked about it a bit. We're happy to help but you guys should probably figure out the internal design first :) thanks Xavier
