On 10/12/2012, at 8:23 PM, Hans Dockter wrote: > <snip> > >> >>> >>> We'd need to introduce 'groovy-lang' and 'scala-lang' too, I guess. >>> >>> >>> This does not publish anything: >>> >>> apply plugin: 'java' >>> >>> This would publish the Java library as a jar + meta-data: >>> >>> apply plugin: 'java' >>> apply plugin: 'java-library' >>> >>> Would this be more like 'jvm-library'? What if you were compiling groovy or >>> scala? Are they different library plugins for different languages? Or is >>> 'java' the language and 'jvm-library' the component type'? >> >> It should be 'jvm-library'. > > A Scala library might behave differently in regard to publishing than a > java-library, as for example Scala is not binary-backwards compatible and you > need to publish multiple libraries (1 for each compiler version). This would > also affect the consuming side. So I'm wondering whether we don't need > scala-library, java-library, …
Possibly. I was thinking of doing something like this: 1. Model the relationship between compiled code and its runtime as a must-use relationship. So, the my-lib variant compiled for Scala 2.8 must use Scala 2.8 at runtime, and the my-lib variant compiled for Scala 2.10 must use Scala version 2.10 at runtime. Resolving this would work exactly the same way as other must-use dependencies: If there's a conflict, attempt to push the graph forward to use Scala 2.10 or pull the graph back to use Scala 2.8 (both while honouring all the dependency constraints) and fail if not possible. 2. Introduce the concept of a 'runtime' or container in which code expects to run, as a new type of component that you can declare a dependency on. This would capture the differences between how runtimes and other types of components are resolved and deployed, and also addresses some of the 'provided' use cases. So, a Scala library isn't a Scala library (from a dependency management point of view), but instead is a jvm library that runs on a certain version of the java runtime and that also happens to need a particular version of the Scala runtime as well. This way, we don't need to model libraries that are Java + Scala or Scala + Groovy or whatever other combinations people have, and we can deal with custom runtimes. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
