« Return to Thread: unmanagedClasspath

Re: unmanagedClasspath

by hdockter :: Rate this Message:

Reply to Author | View in Thread


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-440

All 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


 « Return to Thread: unmanagedClasspath