On 22/04/2011, at 6:58 AM, Peter Niederwieser wrote:
>
> Benjamin Muschko wrote:
>>
>> That's good to know. Thanks! I was actually working on a patch for
>> http://issues.gradle.org/browse/GRADLE-1447 GRADLE-1447 .
>>
>
> You should be able to get to the Groovy Jar with:
>
> ((ProjectInternal)
> project).getServices().get(ClassPathRegistry.class).getClassPathFiles("LOCAL_GROOVY")
>
>
> Not sure if I like GRADLE-1447. Maybe we should make the choice explicit
> with something like "dependencies { groovy localGroovy() }". Having your
> dependencies change silently whenever you upgrade Gradle sounds scary.
I think I agree.
I wonder, though, if a language is a special case, and we should provide a
default implementation for each language, along with the associated compile and
runtime dependencies. We certainly do for Java, although the implementation
varies arbitrarily with the environment, which, to me, is even worse than the
implementation changing arbitrarily with the version of Gradle being used.
To be consistent, if we make you declare an explicit dependency for which
groovy implementation you want, we probably should do the same for which
java/scala/clojure implementation you want. If we do provide a default
implementation, we should do so for all languages, and make the default
relatively independent of Gradle version, and environment.
One option is to add a new type of dependency - a language dependency - where
you specify the language level that you need, and Gradle chooses an appropriate
implementation for you:
dependencies {
compile java(1.5), groovy(1.7)
runtime java(1.6)
}
For the Java language, Gradle would use whichever JVMs it can discover on the
machine, though longer term we might have some way to install the correct JVMs.
Gradle could potentially simulate a java 1.5 jvm using a 1.6 jvm.
The dependency declaration would replace sourceCompatibility and
targetCompatibility (or at very least provide default values for them).
For the Groovy and Scala languages, Gradle would download the appropriate
implementations, unless the version happens to be available locally in, say
$gradleHome/lib.
You would be able to use an artifact dependency instead of a language
dependency (or maybe as well as), to fine-tune the implementation at both
compile and/or runtime:
dependencies {
compile 'org.codehaus.groovy:groovy-all:1.7.10'
}
or
dependencies {
compile groovy(1.7)
runtime 'org.codehaus.groovy:groovy:1.7.10'
}
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
