On Nov 7, 2008, at 11:43 PM, Adam Murdoch wrote:
Hi,
I think we might get some nice benefits from moving the concept of
unmanaged classpaths out of the various tasks and into
Configuration. These are:
- We remove the parallel concepts of configurations and unmanaged
classpaths from all the tasks, and leave configurations (or more
likely FileCollections). This means simpler tasks.
- The unmanaged classpaths can be easily reused by multiple tasks.
Currently, if I add something to the unmanaged classpath for
compile, I have to hunt down all the other places that use the
compile configuration and add it there (providing, of course, they
all support unmanaged classpaths). If I add it to the compile
configuration, then they all just pick it up.
- We could attach meta-info to the items in the unmanaged
classpath, such as which tasks produce them.
- We could mix and match the use of ivy and files for a given
dependency. For instance, I might want to bypass ivy for my intra-
build dependencies by providing File for them, but still have ivy
resolution used for those same dependencies when used outside the
build (actually, its not 'might', I really do want to do this for
some of my builds).
I like this very much. That would provide also a very convenient way
for projects which want to migrate to Gradle and have a lib folder
with unversioned jars for example.
Regarding the mix and match. This would mean a file dependency is
also part of the Ivy module descriptor?
So, how might this look? I can see a few options:
- Add some methods to Configuration which allow unmanaged files to
be added to the Configuration. When Configuration.resolve() is
called, it returns the union of the files provided by ivy and the
set of unmanaged files.
- Make Configuration polymorphic, so that you can have an Ivy
Configuration or an unmanaged Configuration.
- Change Dependency so that an implementation can provide either an
ivy descriptor or a set of files or both, and add an
UnmanagedDependency impl.
I prefer the last option.
Me too. At the end of the day we might have dependencies being tasks.
We plan this for configurations anyway. But both would serve
different use cases.
We would need a term other then 'unmanaged classpath' for this type
of artifact because they aren't necessarily unmanaged, or used for
the classpath.
I would say we can simply skip the term and we can replace it with
file configurations or file dependencies.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
