« Return to Thread: unmanagedClasspath

Re: unmanagedClasspath

by Steve Appling :: Rate this Message:

Adam Murdoch wrote:

>
>
> 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 wonder why this works in some places (eg on my machine, and the
> codehaus bamboo servers) and not others (eg your machine). Which OS and
> java version are you using?
>
>
> Adam
>
>

I think I have been fixing symptoms and not the cause.
The difference was GRADLE_HOME. I'm not sure what changed between 0.6 and now
to cause the problem, but all of the problems I am encountering are the result
of using a GRADLE_HOME with a relative path. I don't have a compelling reason
to have to use it this way, but we were calling the normal gradle.bat file from
another batch file that set up JAVA_HOME, GRADLE_HOME, and JAVA_OPTS. It was
using a relative path to the gradle directory. If you want to fix this, the
following seems to address the cause (although I still don't know what changed
to expose this since 0.6):

Index: BootstrapMain.java
===================================================================
--- BootstrapMain.java (revision 1587)
+++ BootstrapMain.java (working copy)
@@ -63,12 +63,14 @@
if (bootStrapDebug) {
System.out.println("Gradle Home is declared by environment
variable GRADLE_HOME to: " + gradleHome);
}
- System.setProperty("gradle.home", gradleHome);
} else {
if (bootStrapDebug) {
System.out.println("Gradle Home is declared by system property
gradle.home to: " + gradleHome);
}
}
+ gradleHome = (new File(gradleHome)).getAbsoluteFile().getPath();
+ System.setProperty("gradle.home", gradleHome);
+
return gradleHome;
}

--
Steve Appling
Automated Logic Research Team

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

http://xircles.codehaus.org/manage_email

« Return to Thread: unmanagedClasspath