On Jun 15, 2009, at 4:13 PM, Steve Appling wrote:
>
>
> Adam Murdoch wrote:
>> Steve Appling wrote:
>>> I am still having some problems related (I think) to the
>>> unmanagedClasspath changes. I can't get our buildSrc to work now.
>>> Previously we had to do the following in the buildSrc/build.gradle:
>>> compile.groovyClasspath = org.gradle.util.BootstrapUtil.groovyFiles
>>> testCompile.groovyClasspath =
>>> org.gradle.util.BootstrapUtil.groovyFiles
>>>
>>> compile
>>> .unmanagedClasspath(org.gradle.util.BootstrapUtil.gradleClasspath
>>> as File[])
>>>
>>> I have tried several combinations to get this working, but still
>>> can't get the gradle files on the classpath in buildsrc. I get
>>> errors like "unable to resolve class org.gradle.api.Project".
>>>
>>> I am currently just trying to add the gradle files to the compile
>>> classpath using:
>>> dependencies {
>>> compile files(org.gradle.util.BootstrapUtil.gradleClasspath)
>>> }
>>>
>>> This still doesn't work - I would appreciate any other ideas to
>>> try. Perhaps this will make more sense on Monday :)
>>>
>>>
>> This is from the default buildSrc build script, which should work
>> for you:
>> dependencies {
>> compile files(org.gradle.util.BootstrapUtil.gradleClasspath)
>> groovy files(org.gradle.util.BootstrapUtil.groovyFiles)
>> }
>> It looks very similar to what you are trying, so I'm not confident.
>> If you are still getting failures, can you try again with the -s
>> flag, so we can see where the failure is?
>> Adam
>
> I think I have figured this out. BootstrapUtil.gradleClasspath and
> groovyFiles return a list of File objects. Using these with
> Project.files ends up resulting in invalid classpaths because they
> are interpreted as relative paths to the buildSrc directory.
>
> I got this working as follows:
> Index: PathResolvingFileCollection.java
> ===================================================================
> --- PathResolvingFileCollection.java (revision 1582)
> +++ PathResolvingFileCollection.java (working copy)
> @@ -58,7 +58,10 @@
> } else if (element instanceof FileCollection) {
> FileCollection fileCollection = (FileCollection)
> element;
> result.addAll(fileCollection.getFiles());
> - } else {
> + } else if (element instanceof File) {
> + result.add((File) element);
> + }
> + else {
> result.add(project.file(element));
> }
> }
>
> I don't know if you want to make this change or allow project.file
> to handle direct file objects without treating them as relative paths.
>
>
> Also, I'm not sure that the classpath for groovy compiles is working
> the way it is intended. There is a check in GroovyCompile to make
> sure that the classpath for the groovy configuration is not empty,
> but you don't actually have to have the groovy jar in this
> classpath. In GradleUtil.executeIsolatedAntScript (used to actually
> run the compile with ant), it adds all the non-logging gradle jars
> (including groovy-all-1.5.6.jar). So if you added dependencies
> { groovy files('junk') } it would build with the groovy that is
> shipped with gradle (1.5.6). Even if you specify another groovy
> jar, both jars will be on the classpath, which seems dangerous.
Thanks for pointing this out. This issue is on our radar:
http://jira.codehaus.org/browse/GRADLE-440All the GradleUtil.executeIsolatedAntScript logic will eventually be
abolished in favor of a solid, generic approach of executing things in
isolation.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email