On 22/02/2011, at 6:19 AM, Spencer Allain wrote: > For better or worse, in the past gradle revealed the junit jar file onto the > classpath for compileTestJava. The classloader isolation now makes sure that > doesn't happen. > > Now in order to compile Junit tests, some instance of junit jar file needs to > be found in a separate repository. It would be very nice to have some way of > saying useJUnit(['embeddedGradleLibs' : 'true']) or something to that effect > saying that you'd like to use the version of JUnit that ships with gradle and > will be used at runtime. > > Obviously there are cases where you want to have some fixed version of > JUnit/TestNG, but it used to be so convenient to have small standalone > projects that didn't need to define any repositories to be able to run the > test cases. > > gradle is essentially a local repository of very valuable jar files, but > there is no easy convention to expose it as such. It would be great to say > that I have a dependency upon jetty-6.1.25.jar or slf4j-api-1.6.1.jar and > pull it out of gradle directly (when I want to of course - which is different > from when things like that were unintentionally placed along the classpath). > > Maybe like mavenCentral() there would be a gradleLocal() or gradleEmbedded() > repository that would resolve artifact names according to the standard maven > conventions. This would be orthogonal to the auto-testing wiring mentioned > above, but both are attempts at re-using existing jars that are currently > cumbersome to utilize. >
This might be a good option. Could you add a jira issue for this? -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
