Common base plugin for logic targets to demote the Java plugin from its special status


(Meikel Brandmeyer) #1

Is there a plan to extract logic targets, like build, test, compile, assemble, etc. from the Java plugin into a common base plugin, which is language independent? The Java plugin could then be implemented as every other plugin and hook into this logic targets. It would loose its special status it has right now, because it defines these targets.


(Luke Daley) #2

It’s definitely going to happen at some point. There’s no solid plan on when yet though.


(Peter Niederwieser) #3

‘build’ and ‘assemble’ come from the ‘java-base’ (which really serves the role of ‘jvm-lang-base’) and ‘base’ plugin, respectively. ‘compile’ is, at least currently, specific to the language (there is no ‘compile’ task but ‘compileJava’, ‘compileScala’, etc.). This leaves ‘test’, which might need to find a better home. Then again, all current JVM language plugins build upon the ‘java’ plugin, and these are really what the ‘Test’ task targets with its JUnit and TestNG support.


(Meikel Brandmeyer) #4

I checked the source. Obviously the java-base and base plugins already contain all the logical and common targets. Namely: ‘clean’, ‘assemble’, ‘check’ and ‘build’. There is just a ‘compile’ (aka. ‘classes’) missing to hook into.

They just don’t set up the source sets, as well as ‘classes’. This is done in the Java plugin.

So I either have to apply the Java plugin or I have to setup the source sets myself. But then I do have to take care that I do not overwrite the existing source sets from the Java plugin, when it was sourced first. (Or handle the error condition when I try to do so.) Similar someone first applying the clojure plugin and then the java plugin will run into trouble. That is not so nice.

I understand the split between java and java-base in that java-base provides everything necessary to compile java, while the java plugin sets up the source sets in a specific layout as per convention. Maybe there is a new framework-base plugin necessary to keep such things like the source sets? Which go beyond java-base, but are not java related?


(Luke Daley) #5

So I either have to apply the Java plugin or I have to setup the source sets myself …

Take a look at the Groovy and Scala plugins.

Maybe there is a new framework-base plugin necessary to keep such things like the source sets?

It’s not clear what such a plugin would do. There isn’t much point adding actual source sets if you don’t know what is going to happen to them.


(Meikel Brandmeyer) #6

The Scala and Groovy plugins apply the Java plugin. Why should I do that, when I don’t have to compile java sources?

The framework-base plugin would setup the main and test source sets. Then plugins can hook their sources into them. Just as plugins can hook their jar or whatever artifact tasks into ‘assemble’.

To follow your line of reasoning: why does the base plugin define ‘assemble’? There is no point in adding tasks if you don’t know what is going to happen to them.

Hans explained in his talk in Darmstadt last week, that gradle provides the tools to do the job (read: java-base plugin) and for convenience some (optional) frameworks one can use (read: java plugin) which provide out-of-the-box functionality when you follow the convention. At least this is my understanding. Tell me whether I got off tracks here.

The tools part is setting up java sources for compilation etc. added by the java-base plugin. Then the Java plugin adds the framework part. It defines two source sets: “main” and “test”. And adds more default stuff like a jar task etc.

However defining “main” and “test” is in no way java-related. Similar to ‘build’ and ‘check’. What if I have a pure Scala/Groovy/Clojure/younameit project without Java sources? I have to apply the java plugin and check with every run that the non-existing java part is up-to-date. :frowning:


(Luke Daley) #7

I see your point. What’s missing is something that speaks to their being a main and test source set, which is more about project structure than framework/language.

In the meantime, it’s pretty easy to get or create.

Java Style (ish):

SourceSet main = project.sourceSets.findByName("main")
 if (main == null) {
  main = project.sourceSets.create("main")
}

In Groovy you can do this:

SourceSet main = project.sourceSets { main }

That will get or create.


(Meikel Brandmeyer) #8

If I was looking into the issue, would you consider to accept a contribution in this area?


(Luke Daley) #9

We’d absolutely consider it, but can’t promise that we’d end up pulling it in.