On Mon, Dec 10, 2012 at 11:13 PM, Adam Murdoch <[email protected]>wrote:
> > 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. > Cool. Makes sense. Hans > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > >
