Hans Dockter wrote:
I have started to refactor the dependency layer. But this refactoring
is related to the way we deal with archives. And I think it might
makes sense, to refactor our archive handling first.
What about getting rid of the libs and dists bundle stuff. Instead we
would have one archive object which would have this responsibility.
The archive class would have properties like baseName and
defaultTaskName. It would offer similar archive construction methods
as the libs and dists bundles. But it would be much more flexible.
Dealing with archives would be similar how we deal with dependencies.
archives {
baseName = 'myGradle'
libs jar(), jar(classifier: 'x') { ... }
dists zip()
otherConf tar()
}
I really like this idea. Generally, I think this approach, where we use
a domain model and generate tasks from this domain model, is much much
better than the approach where we use the tasks to describe the domain
(as we currently do with archives, and tests, for example). It allows us
to structure the DSL to fit the domain, rather than trying to coerce the
domain over a number of tasks. It also means that the same information
can be used by multiple tasks, or things other than tasks.
I wonder if we shouldn't apply this to our tests, and have a tests { }
container which defines things like the test suites, which framework to
use, coverage, etc.
Do you think the archives { } container will be added by a plugin or
part of the core? Currently its a bit of a mix, where some bits are
provided by the core and some by the java plugin.
Every configuration has a property: TaskDependency archives. We could
provide a synthetic task to build those archives, let's say if people
call libsArchives or otherConfArchives (for convenience we might
continue to provided the libs and dists task).
What would we do with the artifacts of a configuration which are not
archives? Perhaps we should generalise this property to be 'artifacts'
instead of 'archives'.
The refactoring above would make the project dependencies refactoring
very easy.
And we would play the same game for uploading. No more uploadLibs or
uploadDists.
uploads {
dists someResolver(...)
...
}
What does this define exactly? Is 'dists' an archive? A type of archive?
a configuration?
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
