Hi all,
I'm working on our new publication stuff. The question has come up of where the
different components need to to go to support a standalone dependency
management library.
I can't remember ever having the conversation on just what this would mean.
That is, exactly what services would a standalone dependency management library
provide, and what would the API be like?
Note: this is not a pressing issue. For the time being we'll be developing in a
new module, but I thought this would be a good discussion to start now.
For dependency resolution, you in theory don't need much. It's conceivable that
you don't even need a Project object. For publication, things are different.
A quick example:
interface Publication extends Buildable {}
class PublishTask extends DefaultTask {
@Input Publication publication
ArtifactRepository repository
}
The implementation of this task would use all kind of internal machinery for
working out just how to move this publication's files to the repository. If we
design this as *the* public API for invoking publication, it starts to look
like our standalone dependency management library gets pretty big. It needs to
have projects, a task graph etc.
I would think that this is too much. To use our dependency management stuff,
you shouldn't need a Project and tasks. So this would mean that (eventually)
there needs to be public API that works outside of a task (e.g.
publication.publish(repository) - just illustrative).
There are other issues of course. If a publication is to be used standalone
(without task machinery), then does Buildable make sense? If Publication has to
work standalone, making it Buildable makes it too easy to make design decisions
based on being in a task environment.
These are all solvable issues, and the point of this email is not to try and
solve them. The point is to explore exactly what a standalone dependency
management library means.
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
