unmanagedClasspath

[Steve Appling]

While updating our build to include the latest changes in the trunk, I ran into some issues related
to the removal of unmanagedClasspath.  I finally got our build working, but I'm not sure I like the
direction.

We chose to store some non-unit tests in different directories under src, so we have src/main,
src/test, src/test-functional.  We have a set of functional test tasks similar to the unit test
ones: processFunctionalTestResources, compileFunctionalTests, and functionalTest.

Each of these tasks previously used the unmanagedClasspath property to add the appropriate classes
directory similar to what is done by the JavaPlugin for the unit test tasks.  For example, the
compileFunctionalTests task added the unit test output directory by using:
    unmanagedClasspath = compileTests.unmanagedClasspath + project.convention.testClassesDir

I followed the example in the current JavaPlugin and ended up with something like this in my new
gradle file:

    dependencies.add('functionalTestCompile', [
       getDisplayName: { "Anonymous File Collection" },
       getFiles : { Collections.singleton(project.convention.testClassesDir)}
    ] as AbstractFileCollection)

I didn't like having the internal interface AbstractFileCollection in my gradle file, so I added
support for Files to the SelfResolvingDependencyFactory so that you could just use:
    dependencies.add('functionalTestCompile', project.convention.testClassesDir)

I'll be glad to post a patch for this if anyone thinks this would be useful.

I still don't like this solution, however.  I may just not understand how this was intended to work
in 0.7.  The distinctions between the SelfResolvingDependency and other types of Dependencies are
way too subtle for me.  It is not obvious that passing certain types of objects to dependencies.add
results in "unmanaged" additions to the classpath.  I would like the "unmanaged" aspect of this to
be much more explicit. This seems to me like a different type of path on a configuration, not a
different type of dependency - it doesn't impact the DAG.  I think I might prefer an
addUnmanagedPath method on Configuration.


--
Steve Appling
Automated Logic Research Team

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

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Steve Appling wrote:

> While updating our build to include the latest changes in the trunk, I
> ran into some issues related to the removal of unmanagedClasspath.  I
> finally got our build working, but I'm not sure I like the direction.
>
> We chose to store some non-unit tests in different directories under
> src, so we have src/main, src/test, src/test-functional.  We have a
> set of functional test tasks similar to the unit test ones:
> processFunctionalTestResources, compileFunctionalTests, and
> functionalTest.
>
> Each of these tasks previously used the unmanagedClasspath property to
> add the appropriate classes directory similar to what is done by the
> JavaPlugin for the unit test tasks.  For example, the
> compileFunctionalTests task added the unit test output directory by
> using:
>    unmanagedClasspath = compileTests.unmanagedClasspath +
> project.convention.testClassesDir
>
> I followed the example in the current JavaPlugin and ended up with
> something like this in my new gradle file:
>
>    dependencies.add('functionalTestCompile', [
>       getDisplayName: { "Anonymous File Collection" },
>       getFiles : {
> Collections.singleton(project.convention.testClassesDir)}
>    ] as AbstractFileCollection)
>

You can use the Project.files() method:

dependencies.add('functionalTestCompile', files
{project.convention.testClassesDir})

You don't necessarily need to use a configuration for this, either (you
did in earlier versions of Gradle). This would work:

compileFunctionalTests.classpath = files(configurations.testCompile,
project.convention.testClassesDir)

> I didn't like having the internal interface AbstractFileCollection in
> my gradle file, so I added support for Files to the
> SelfResolvingDependencyFactory so that you could just use:
>    dependencies.add('functionalTestCompile',
> project.convention.testClassesDir)
>
> I'll be glad to post a patch for this if anyone thinks this would be
> useful.
>

Do we need this, given you can use the files() method?

> I still don't like this solution, however.  I may just not understand
> how this was intended to work in 0.7.  The distinctions between the
> SelfResolvingDependency and other types of Dependencies are way too
> subtle for me.  It is not obvious that passing certain types of
> objects to dependencies.add results in "unmanaged" additions to the
> classpath.  I would like the "unmanaged" aspect of this to be much
> more explicit. This seems to me like a different type of path on a
> configuration, not a different type of dependency - it doesn't impact
> the DAG.

It will, for generated files. For example, adding the classes dir into a
configuration will add the compile task into the dependencies of any
task using the configuration.

This step is the very start of the teasing apart of the ivy dependency
model into a richer model. I think dependencies have several independent
aspects, which you should be able to control for a given dependency:

1. Where do it's artifacts come from? Previously, we had one possible
source: they are located in a repository somewhere. Now we have two
sources: you can use a repository, or you can explicitly specify the
files. We can now add more: eg the from the current Gradle instance.

2. Where can an external project find the dependency? That is, what
meta-info should be included in the project descriptor when it is
published, if any?

3. How are the artifacts produced? That is, which tasks should be
executed in order to produce the artifacts for the dependency?

I think you should be able to declare any combination of these for a
given dependency. Right now, we have a small, hard-coded set of
combinations:

- file: the artifacts are explicit, they are not visible to an external
project, and they are not built

- module: find the artifacts in a repository, external projects find
them in a repository, and they are not built.

- project: find the artifacts in a repository, external projects find
them in a repository, and they are built by the appropriate tasks in the
target project.

Some other useful, and missing, variations:

- The dependency is available locally, but uses some naming scheme which
doesn't work with flatDir. You should be able to specify the artifacts
explicitly, but also include the dependency in the published descriptor,
so that external projects use the dependency out of a repository.

- Your project uses a directory which is also published as an archive,
such as classes dir. You should be able to declare a dependency which
uses the directory within the project, and the published archive in
external projects. If you use the dependency, the appropriate tasks are
executed to build the contents of the directory.

- You use a dependency which is built by an external project on the
local machine. You should be able to declare a dependency which uses the
artifacts built by that external project, and also knows how to run a
build for that external project.

- Gradle API or Groovy or Ant. Gradle should be able to give you a
dependency which uses the appropriate jars out of the current Gradle
distribution, or out of a given Groovy or Ant distribution, and also
includes the dependency in the published descriptor.

To me, this process is about allowing the dependency model to scale down
in complexity to simple cases, and up in complexity to cases we haven't
thought of yet. We plan to do this by allowing the different aspects of
a dependency to be composed into whichever combination you like, rather
than providing fixed combination. This scales down, because you can
ignore the aspects you don't care about, and it scales up, because you
can control each and every aspect of any dependency.

At its most basic, a configuration is just a named set of files. It
makes perfect sense, I think, to be able to add a collection of files
directly to a configuration, if I don't want or need to provide any
meta-info about those files, or use any repositories, or publish the
configuration.

Digging a bit deeper, a configuration is made up of a set of
dependencies, each of which resolves to a set of files and has some
meta-info associated with it. So it also makes sense to me that, when I
do add a collection of files to a configuration, the collection is added
as a dependency. This means I can, if I want, specify some or all of the
meta-info about those files: here's some files to use, and if an
external project needs them, they're also known to the world as
groovy-all version 1.6.2, and if I need to use them, they are built by
the 'downloadGroovy' task.


Adam


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

    http://xircles.codehaus.org/manage_email

[Steve Appling]

Adam Murdoch wrote:

>
>
> Steve Appling wrote:
>> While updating our build to include the latest changes in the trunk, I
>> ran into some issues related to the removal of unmanagedClasspath.  I
>> finally got our build working, but I'm not sure I like the direction.
>>
>> We chose to store some non-unit tests in different directories under
>> src, so we have src/main, src/test, src/test-functional.  We have a
>> set of functional test tasks similar to the unit test ones:
>> processFunctionalTestResources, compileFunctionalTests, and
>> functionalTest.
>>
>> Each of these tasks previously used the unmanagedClasspath property to
>> add the appropriate classes directory similar to what is done by the
>> JavaPlugin for the unit test tasks.  For example, the
>> compileFunctionalTests task added the unit test output directory by
>> using:
>>    unmanagedClasspath = compileTests.unmanagedClasspath +
>> project.convention.testClassesDir
>>
>> I followed the example in the current JavaPlugin and ended up with
>> something like this in my new gradle file:
>>
>>    dependencies.add('functionalTestCompile', [
>>       getDisplayName: { "Anonymous File Collection" },
>>       getFiles : {
>> Collections.singleton(project.convention.testClassesDir)}
>>    ] as AbstractFileCollection)
>>
>
> You can use the Project.files() method:
>
> dependencies.add('functionalTestCompile', files
> {project.convention.testClassesDir})
>
> You don't necessarily need to use a configuration for this, either (you
> did in earlier versions of Gradle). This would work:
>
> compileFunctionalTests.classpath = files(configurations.testCompile,
> project.convention.testClassesDir)
>

This is exactly what I needed in this case - thanks.

>> I didn't like having the internal interface AbstractFileCollection in
>> my gradle file, so I added support for Files to the
>> SelfResolvingDependencyFactory so that you could just use:
>>    dependencies.add('functionalTestCompile',
>> project.convention.testClassesDir)
>>
>> I'll be glad to post a patch for this if anyone thinks this would be
>> useful.
>>
>
> Do we need this, given you can use the files() method?

Nope, the files method is fine.

>
>> I still don't like this solution, however.  I may just not understand
>> how this was intended to work in 0.7.  The distinctions between the
>> SelfResolvingDependency and other types of Dependencies are way too
>> subtle for me.  It is not obvious that passing certain types of
>> objects to dependencies.add results in "unmanaged" additions to the
>> classpath.  I would like the "unmanaged" aspect of this to be much
>> more explicit. This seems to me like a different type of path on a
>> configuration, not a different type of dependency - it doesn't impact
>> the DAG.
>
> It will, for generated files. For example, adding the classes dir into a
> configuration will add the compile task into the dependencies of any
> task using the configuration.
>
> This step is the very start of the teasing apart of the ivy dependency
> model into a richer model. I think dependencies have several independent
> aspects, which you should be able to control for a given dependency:
>
> 1. Where do it's artifacts come from? Previously, we had one possible
> source: they are located in a repository somewhere. Now we have two
> sources: you can use a repository, or you can explicitly specify the
> files. We can now add more: eg the from the current Gradle instance.
>
> 2. Where can an external project find the dependency? That is, what
> meta-info should be included in the project descriptor when it is
> published, if any?
>
> 3. How are the artifacts produced? That is, which tasks should be
> executed in order to produce the artifacts for the dependency?
>
> I think you should be able to declare any combination of these for a
> given dependency. Right now, we have a small, hard-coded set of
> combinations:
>
> - file: the artifacts are explicit, they are not visible to an external
> project, and they are not built
>
> - module: find the artifacts in a repository, external projects find
> them in a repository, and they are not built.
>
> - project: find the artifacts in a repository, external projects find
> them in a repository, and they are built by the appropriate tasks in the
> target project.
>
> Some other useful, and missing, variations:
>
> - The dependency is available locally, but uses some naming scheme which
> doesn't work with flatDir. You should be able to specify the artifacts
> explicitly, but also include the dependency in the published descriptor,
> so that external projects use the dependency out of a repository.
>
> - Your project uses a directory which is also published as an archive,
> such as classes dir. You should be able to declare a dependency which
> uses the directory within the project, and the published archive in
> external projects. If you use the dependency, the appropriate tasks are
> executed to build the contents of the directory.
>
> - You use a dependency which is built by an external project on the
> local machine. You should be able to declare a dependency which uses the
> artifacts built by that external project, and also knows how to run a
> build for that external project.
>
> - Gradle API or Groovy or Ant. Gradle should be able to give you a
> dependency which uses the appropriate jars out of the current Gradle
> distribution, or out of a given Groovy or Ant distribution, and also
> includes the dependency in the published descriptor.
>
> To me, this process is about allowing the dependency model to scale down
> in complexity to simple cases, and up in complexity to cases we haven't
> thought of yet. We plan to do this by allowing the different aspects of
> a dependency to be composed into whichever combination you like, rather
> than providing fixed combination. This scales down, because you can
> ignore the aspects you don't care about, and it scales up, because you
> can control each and every aspect of any dependency.
>
> At its most basic, a configuration is just a named set of files. It
> makes perfect sense, I think, to be able to add a collection of files
> directly to a configuration, if I don't want or need to provide any
> meta-info about those files, or use any repositories, or publish the
> configuration.
>
> Digging a bit deeper, a configuration is made up of a set of
> dependencies, each of which resolves to a set of files and has some
> meta-info associated with it. So it also makes sense to me that, when I
> do add a collection of files to a configuration, the collection is added
> as a dependency. This means I can, if I want, specify some or all of the
> meta-info about those files: here's some files to use, and if an
> external project needs them, they're also known to the world as
> groovy-all version 1.6.2, and if I need to use them, they are built by
> the 'downloadGroovy' task.
>
>
> Adam

I like the flexibility that you are suggesting and would love to see some of
these changes.

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 :)


--
Steve Appling
Automated Logic Research Team


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

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

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


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

    http://xircles.codehaus.org/manage_email

[Steve Appling]

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

With
     compile files(org.gradle.util.BootstrapUtil.gradleClasspath)
     groovy files(org.gradle.util.BootstrapUtil.groovyFiles)
I get
  java.lang.NoClassDefFoundError: org/codehaus/groovy/ant/Groovyc
  Caused by: java.lang.ClassNotFoundException: org.codehaus.groovy.ant.Groovyc

If I change the groovy dependency to:
    groovy      'org.codehaus.groovy:groovy-all:1.5.6'

it then finds groovyc, but I get lots of errors like:
C:\Working\ALC\SCC\webctrl\main\exp\modularization_prep\modules\buildSrc\src\main\groovy\tasks\Doc.groovy:
36: unable to resolve class org.gradle.api.Project

--
Steve Appling
Automated Logic Research Team

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

    http://xircles.codehaus.org/manage_email

[Steve Appling]

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.

--
Steve Appling
Automated Logic Research Team

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

    http://xircles.codehaus.org/manage_email

[hdockter]

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

[Steve Appling]

Steve Appling wrote:

> While updating our build to include the latest changes in the trunk, I
> ran into some issues related to the removal of unmanagedClasspath.  I
> finally got our build working, but I'm not sure I like the direction.
>
> We chose to store some non-unit tests in different directories under
> src, so we have src/main, src/test, src/test-functional.  We have a set
> of functional test tasks similar to the unit test ones:
> processFunctionalTestResources, compileFunctionalTests, and functionalTest.
>
> Each of these tasks previously used the unmanagedClasspath property to
> add the appropriate classes directory similar to what is done by the
> JavaPlugin for the unit test tasks.  For example, the
> compileFunctionalTests task added the unit test output directory by using:
>    unmanagedClasspath = compileTests.unmanagedClasspath +
> project.convention.testClassesDir
>
> I followed the example in the current JavaPlugin and ended up with
> something like this in my new gradle file:
>
>    dependencies.add('functionalTestCompile', [
>       getDisplayName: { "Anonymous File Collection" },
>       getFiles : {
> Collections.singleton(project.convention.testClassesDir)}
>    ] as AbstractFileCollection)
>
> I didn't like having the internal interface AbstractFileCollection in my
> gradle file, so I added support for Files to the
> SelfResolvingDependencyFactory so that you could just use:
>    dependencies.add('functionalTestCompile',
> project.convention.testClassesDir)
>
> I'll be glad to post a patch for this if anyone thinks this would be
> useful.
>
> I still don't like this solution, however.  I may just not understand
> how this was intended to work in 0.7.  The distinctions between the
> SelfResolvingDependency and other types of Dependencies are way too
> subtle for me.  It is not obvious that passing certain types of objects
> to dependencies.add results in "unmanaged" additions to the classpath.  
> I would like the "unmanaged" aspect of this to be much more explicit.
> This seems to me like a different type of path on a configuration, not a
> different type of dependency - it doesn't impact the DAG.  I think I
> might prefer an addUnmanagedPath method on Configuration.
>
>

After a little more consideration I think I would prefer updating Project.file
to handle File objects.  If the file parameter isAbsolute, then it should be
used directly, otherwise a new file relative to the project directory should be
used.

Should I make a Jira and patch for this?

--
Steve Appling
Automated Logic Research Team

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

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

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


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

    http://xircles.codehaus.org/manage_email

[Russel Winder-4]

On Tue, 2009-06-16 at 16:04 +1000, Adam Murdoch wrote:
[ . . . ]
> 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?

Out of the blue contribution:

I think I am finding that whenever Gradle spawns a new process, the new
process does not seem to have inherited the environment and properties
of the original Gradle process as seems to happen with Ant and Gant --
except on Canoo CruiseControl.  This can lead to interesting
incompatibilities of classpath and other state between parts of a build
-- especially test runs.

Certainly for some of the Gant tests, I have to force the classpath so
that tests that run fine on my local Buildbot using Gant, local manual
Ant and Gant runs, and on Codehaus Bamboo using Ant, run correctly on
Canoo CruiseControl using Ant and local manual Gradle runs (which
otherwise fail with process fail related causes due to classpath
issues).

So perhaps this is an environment rather than OS issue per se?

--
Russel.
=============================================================================
Dr Russel Winder      Partner
                                            xmpp: russel@...
Concertant LLP        t: [phone], [phone]
41 Buckmaster Road,   f: [phone]   voip: sip:russel.winder@...
London SW11 1EN, UK   m: [phone]   skype: russel_winder

[Steve Appling]

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