Re: unmanagedClasspath

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