On Jan 4, 2009, at 8:56 PM, Adam Murdoch wrote:
<snip>
For the JUnit / TestNG dependencies we need to have some way to
have finer control over the resolved dependencies, with this I mean
we need to be able to get a list of all the files that represent
the JUnit/TestNG dependency so we can use the file paths to create
an Ant path so we can do a taskdef with the correct files
( currently I scan the classpath files for a file that starts with
testng - not a very nice/safe way of doing it). (This sentence
contained way to many 'so we can do's :P).
This also applies to our use of groovy. I think the approach is good
(ie the library has already been declared in the compile/runtime
configurations, so let's just use it from there). We can improve the
implementation by, say, providing a way to resolve just a particular
module (junit/testng/groovy) from a configuration.
I think we can and should make the configuration object really
powerful in terms of resolving with dependency filtering. I will
discuss this issue as one of the dependency refactoring issues in
another posting.
<snip>
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
