On 8 April 2013 11:05, Luke Daley <[email protected]> wrote: > > On 30/03/2013, at 11:57 PM, Adam Murdoch <[email protected]> > wrote: > > > Hi, > > > > With the new source sets DSL, you can define multiple source sets of > various types and multiple binaries and attach source sets as inputs to > binaries. Each source set can be used as source input to multiple binaries, > and each binary can accept multiple source sets as input. > > > > Each source set added to a binary is compiled separately from the other > inputs. The idea here is this allows you to compose a binary from source > sets compiled in various different ways. To jointly compile all source for > a binary, you first compose the source into a single source set and then > attach that to the binary. So, for each (source-set, binary) edge in the > graph, there is a compile task, and we need a naming scheme for these. > > This is a little hard for me to visualise for some reason. Can you give a > DSL example? > > > For this discussion 'compile task' just means some kind of > transformation task, like processing resources or compiling some java or > generating some byte code or whatever. Just assume that whatever we come up > with for compilation works can be tweaked to work for processing resources > and other things. > > > > Let's assume that each source set and binary has some kind of unique > name or path. Given this, some kind of expressive naming scheme such as the > one we use for publishing is a good option, something like > `compile${SourceSet}For${Binary}Classes`: > > > > source { > > main { > > java { …. } > > java5 { …. } > > } > > } > > > > binaries { > > jvm { > > main(ClassDirectoryMain) { > > source source.main.java > > source source.main.java5 > > } > > } > > } > > > > So, you'd end up with `compileMainJavaForMainClasses` and > `compileMainJava5ForMainClasses` as task names. You could argue that these > names are kind of awkward. However, these are worker tasks that usually you > wouldn't run (you'd run `gradle classes` instead) or configure (the compile > settings will mostly be inferred from the configuration of the source set > and the binary) or declare a dependency on (you'd use the binary as input > instead). > > > > One issue here is what we do about backwards compatibility. The `java` > and `java-base` plugins add adapters for each old source set and a binary > for its output, so that you can use the new model with the old plugins. The > idea is that we'll migrate everything that consumes the old language model > across to consume this new model instead (this would include the code > quality, IDE, sonar, publishing plugins), so that they continue to work > with the old language plugins but can also deal with new and interesting > conventions (e.g. the Android plugin conventions). > > > > For the compile tasks that are added for these legacy source sets, we > need to use a backwards compatible naming scheme, perhaps something like: > > > > - When compiling the `main.java` legacy source set for the `main` legacy > binary, the task is called `compileJava`. > > - When compiling the `${name}.java` legacy source set for the `${name}` > legacy binary, the task is called `compile${Name}Java` > > - Otherwise, to compile the `${sourceSet}` source set for the > `${binary}` binary, the task is called > `compile${SourceSet}For${Binary}Classes` > > > > This would mean that we'd use a different naming scheme for compiling > `main.java` for the `main` binary if you defined these via the `java` > plugin, vs. some new plugin or directly in the DSL. Eventually, we'd > deprecate and remove the legacy source sets and then everything would use a > consistent, if somewhat verbose, naming scheme. > > > > Another option would be to drop the legacy constraint from the rules > above: > > > > - When compiling the `main.${lang}` source set for the `main` binary, > the task is called `compile${Lang}`. > > - When compiling the `${function}.${lang}` source set for the > `${function}` binary, the task is called `compile${Function}${Lang}`. > > - Otherwise, to compile the `${sourceSet}` source set for the > `${binary}` binary, the task is called > `compile${SourceSet}For${Binary}Classes`. > > > > So, for our example above, we'd end up with `compileJava` and > `compileJava5`. What this means is that we somewhat nicer names for the > common cases. > > > > > > Thoughts? > > I like the "collapse-on-main" idiom and I think we should embrace it. It's > so common to have one thing that this special case handling is justified to > me. So, the "drop the legacy constraint" scheme works for me. > > I'd like to make it a stronger idiom/convention though eventually. I think > this would just mean documenting it in some kind of style guide and > providing some (public) utilities for doing the collapsing in a consistent > way. > > I'm not entirely clear on the "compile${SourceSet}For${Binary}Classes" > case though as I don't fully understand the implications of aggregation. > I'm not sure if it matters for this discussion or not though. > > > Alternatives? > > I guess an alternative is for us not to be too concerned about the awkwardness of these generated task names, and instead focus efforts on a way to allow anonymous tasks (or duplicate task names) along with task execution based on attributes. (As we've discussed before).
This would allow us to execute "all compile tasks for the 'main' binary" or "all compile tasks for the 'java.main' sourceset". This particular distinction is a bit artificial, but this would lend itself to "publish all artifacts to the 'repo1' repository", which is not (artificial). So something like: publish[repository:'repo1'] -- Darrell (Daz) DeBoer Principal Engineer, Gradleware http://www.gradleware.com Join us at the Gradle Summit 2013, June 13th and 14th in Santa Clara, CA: http://www.gradlesummit.co <http://www.gradlesummit.com/>
