Re: unmanagedClasspath

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