some changes for mixed language projects
|
View:
New views
4 Messages
—
Rating Filter:
Alert me
|
 |
some changes for mixed language projects
by Adam Murdoch-2
::
Rate this Message:
Hi,
I've been making some changes to allow any combination of Java, Groovy and Scala source to be used for a project. The guts of this change is that the 'compile' task of each source set has been split into: - compileJava: of type Compile, compiles every thing in src/main/java using javac - compileGroovy: of type GroovyCompile, compiles everything in src/main/groovy using groovyc+javac. Handles joint groovy and java compilation - compileScala: of type ScalaCompile, compiles everything in src/main/scala using scalac+javac. Handles joint scala and java compilation - compile: dependsOn compileJava, compileGroovy, compileScala, processResources compileGroovy and compileScala are added by the Groovy and Scala plugins, respectively. The rest are added by the Java plugin. We don't handle joint Groovy, Scala and Java compilation. I've also made some changes to the lifecycle tasks: - libs and dists have been merged into assemble - moved the check task from the code quality plugin to the java plugin - changed check to depend on test Adam --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: some changes for mixed language projects
by Steve Appling
::
Rate this Message:
Adam Murdoch wrote: > Hi, > > I've been making some changes to allow any combination of Java, Groovy > and Scala source to be used for a project. The guts of this change is > that the 'compile' task of each source set has been split into: > > - compileJava: of type Compile, compiles every thing in src/main/java > using javac > > - compileGroovy: of type GroovyCompile, compiles everything in > src/main/groovy using groovyc+javac. Handles joint groovy and java > compilation > > - compileScala: of type ScalaCompile, compiles everything in > src/main/scala using scalac+javac. Handles joint scala and java compilation > > - compile: dependsOn compileJava, compileGroovy, compileScala, > processResources > > compileGroovy and compileScala are added by the Groovy and Scala > plugins, respectively. The rest are added by the Java plugin. > > We don't handle joint Groovy, Scala and Java compilation. > > I've also made some changes to the lifecycle tasks: > > - libs and dists have been merged into assemble > - moved the check task from the code quality plugin to the java plugin > - changed check to depend on test > > > Adam > I don't have a better answer, but I still feel it is awkward to have the language in the task name. Even if I could always use the compile task from the command line (because of the dependency), I have to use the task with the language name when setting up the options. I guess it's just habit, but I keep using compile.options. -- Steve Appling Automated Logic Research Team --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
|
|
Re: some changes for mixed language projects
by Tom Eyckmans
::
Rate this Message:
2009/9/17 Adam Murdoch <a@...> Hi, Ok now I think I understand the reason for the language name in the name of the compile task. But I would have expected this to be incorporated in some sort of typing of source sets, so the name of the language is in the build script and doesn't have to be repeated on the command line. This shows that there should be 2 different typings for source sets, what type of code it represents main code or test code, and in which language the code is written. and as mentioned also in an other thead have compileMain for the main source set but also have compile that compiles all the 'main' source sets. We don't handle joint Groovy, Scala and Java compilation.
|
|
|
Re: some changes for mixed language projects
by Adam Murdoch-2
::
Rate this Message:
Steve Appling wrote: > > > Adam Murdoch wrote: >> Hi, >> >> I've been making some changes to allow any combination of Java, >> Groovy and Scala source to be used for a project. The guts of this >> change is that the 'compile' task of each source set has been split >> into: >> >> - compileJava: of type Compile, compiles every thing in src/main/java >> using javac >> >> - compileGroovy: of type GroovyCompile, compiles everything in >> src/main/groovy using groovyc+javac. Handles joint groovy and java >> compilation >> >> - compileScala: of type ScalaCompile, compiles everything in >> src/main/scala using scalac+javac. Handles joint scala and java >> compilation >> >> - compile: dependsOn compileJava, compileGroovy, compileScala, >> processResources >> >> compileGroovy and compileScala are added by the Groovy and Scala >> plugins, respectively. The rest are added by the Java plugin. >> >> We don't handle joint Groovy, Scala and Java compilation. >> >> I've also made some changes to the lifecycle tasks: >> >> - libs and dists have been merged into assemble >> - moved the check task from the code quality plugin to the java plugin >> - changed check to depend on test >> >> >> Adam >> > > I don't have a better answer, but I still feel it is awkward to have > the language in the task name. Even if I could always use the compile > task from the command line (because of the dependency), I have to use > the task with the language name when setting up the options. I guess > it's just habit, but I keep using compile.options. I suspect it's habit. How could you possibly not know the target language when you want to configure the compiler for that language? One benefit of having the target language in the task name is that it makes it explicit which compiler is being configured. Previously, the name 'compile' might have referred to a Compile, GroovyCompile or ScalaCompile task, and compile.options.something is not clear what I'm configuring here. I need to go and look for the appropriate usePlugin() call, which might be in another build script, such as the root project. compileJava.options.something compileScala.options.something is better at self-describing. Plus I get a failure at evaluation time if I've made a mistake. Another benefit is that you now have the possibility to configure javac differently for compiling stand-alone Java, and for joint compilation. There's a few negatives to the current approach: * It's noisy. You get compileJava/compileTestJava regardless of whether you have any stand-alone Java in the project. I guess most Groovy or Scala projects don't have stand-alone Java We could address this by fixing up gradle -t to do something smarter by default. Another option would be to chop up the Java/Groovy/Scala plugins into a few pieces: 1. The lifecycle: Adds tasks like clean, assemble, check, build, buildNeeded, etc. 2. The basic source set stuff: Adds the ability to define source sets, but they don't do anything. Wires them into the lifecycle. 3. The standard source sets: Adds the 'main' and 'test' source sets, plus their configurations and sets up their classpaths. 4. The Java compile tasks: Each source set gets a compileJava task and a 'java' source property. 5. The Groovy compile tasks: Each source set gets a compileGroovy task and a 'groovy' source property. 6. The Scala compile tasks: Each source set gets a compileScala task and a 'scala' source property. Then: usePlugin 'java' would apply 1,2, 3, 4 usePlugin 'groovy' would apply 1,2,3,5 usePlugin 'scala' would apply 1,2,3,6 * If you want to configure javac for both stand-alone Java and joint Java Groovy compilation, you have to configure both compileJava and compileGroovy We can address this by adding the options to the source set object: source { main { javac.someJavacOption = '-Xsomething groovyc.someGroovycOption = 'some groovy thing' scalac.someScalacOption = 12 } } Adam --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email |
| Free embeddable forum powered by Nabble | Forum Help |
