On Jan 1, 2009, at 10:02 PM, Adam Murdoch wrote:
Tom Eyckmans wrote:
Hi,
I've got a dilema...
As you know I'm working on the TestNG framework support. Currently
the dependency on TestNG is added when the TestFramework
implementation class is configured (doFirst on the test compile
task). I'm not sure if this is the most transparent way. Perhaps it
is better not do add the dependency in code an have the dependency
stated in the dependency block so all dependencies are stated in
one place.
Shouldn't TestNG already be included in the testCompile
configuration? The test code has a direct compile-time dependency on
TestNG, so it really should be included.
I can think of a few similar cases, where a plugin provides some
kind of integration with a library with an API that the application
code uses directly. In each case, we use a different approach for
finding the library, which I don't think is very good. I think it's
important to have a consistent approach to this problem. I don't
really care which one we choose.
Current integrations for libraries used by application code
(excluding the build file):
- java. API + runtime provided by the jvm the build is running in,
and we assume the version is the appropriate one for the project. No
way to declare which version to use.
Right now you have three switches:
JAVA_HOME for the JDK Gradle is using
Compile: executable options to choose the JDK for compiling
Test: jvm option to choose the JRE for running the tests.
We might come up with a nicer way to define the project JDK/JRE.
- groovy. API + runtime must be declared in a separate 'groovy'
configuration.
Theoretically it is a similar scenario to Java. But there are
important practical difference.
- Groovy code is much more sensitive to the Groovy version than Java
code. Java's compatibility is extremely reliable, in contrast to
Groovy. If Gradle would pick up the Groovy which is installed on the
machine, we would have many issues due to that (e.g. we get an NPE if
we run Gradle with Groovy 1.5.8). So bundling Groovy makes Gradle more
reliable.
- Our target group are Java developers. We can expect that Java is
installed on there machines. We can't expect the same for Groovy. So
bundling Groovy s convenient for many of our users.
- Groovy is a library on top of Java. Dealing with Java as a library
would probably not work out.
So I think it is OK to have different approaches if there are reasons
for this.
- junit. API must be declared in 'testCompile' configuration.
Runtime is provided by Gradle's lib directory. No way to declare
which version to use for runtime.
Right. We have to improve this.
- testng. API must be declared in 'testCompile' configuration.
Runtime provided by an implicit dependency added by one of the tasks.
- servlet. API must be declared in 'compile' configuration. Runtime
is provided by Gradle's lib directory. No way to declare which
version to use for runtime.
Right. I'm looking forward to our future plugin system.
- gradle. API + runtime provided by version of Gradle the build is
running in. The build file has to use ClassPathUtils and perform
some unmanaged compile classpath magic. No way to declare which
version to use.
The only way right now we use the Gradle classpath is when building
the build sources. I'm looking forward to our OSGi kernel to make this
nicer. But why would we want to declare the usage of the different
Gradle version within Gradle?
I don't see why we shouldn't be using the same approach for all of
these.
I agree for groovy, junit, testng and servlet. I'm not sure about Java.
Personally, I prefer that the dependency is explicit in the build
file. For some kinds of dependencies (java + gradle) the best we can
do for starters is to simply assert that the current JVM or Gradle
version is compatible with the desired versions. In fact, for all
our integrations, we should assert that the desired runtime version
is one that works with the integration.
Right.
A potential convenience would be to add an implicit dependency with
a reasonable default version, when we can determine the dependency
exists from the context, such as adding junit or testng when tests
are present, or groovy when using the groovy plugin, or gradle when
using the plugin plugin.
We should think about this.
It would be nice if we just reached into the runtime/testRuntime
configurations and found the runtime there, rather than adding
special configuration for each integration.
Good point.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
