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