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).
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.
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.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
