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.
- groovy. API + runtime must be declared in a separate 'groovy'
configuration.
- 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.
- 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.
- 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.
I don't see why we shouldn't be using the same approach for all of these.
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.
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.
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.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
