2009/1/16 Adam Murdoch <a...@rubygrapefruit.net>
>
>
> 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.
I like this idea a lot, mainly because when we would add coverage support
now it would end up in the test task and we would just end up with to many
responsibilities in the test task.
>
>
> 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'.
I like 'artifacts' over 'archives' because it would allow us to expand
beyond Java projects (like what is already happening on the users list for
C/CPP).
>
>
> 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?
Currently we have for example compile for pulling dependencies (artifacts)
in, it would nice to have dists, sources, javadoc for pushing (artifacts)
out. So it would also be nice to be able to add outgoing configurations:
artifacts {
addConfiguration('examples') // because the addConfiguration is in the
artifacts block we can mark it as an outgoing configuration
// addConfiguration('dists', 'runtime') implicit - the dists
configuration depends on runtime allowing us to setup the Class-Path in
MANIFEST.MFautomatically
// multiple artifacts in outgoing configuration
examples jar() { ... },
zip() { ... }
sources jar() { ... }
javadoc jar() { ... }
}
upload {
// like we do for pulling dependencies in
addMavenRepo('maven', ....)
addFtp('webFtp', ...)
// but here we use the configurations to state what artifacts we want to
publish/upload
webFtp examples,
sources,
javadoc,
dists // publish everything to web
maven sources,
javadoc,
dists
}
>
>
> Adam
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
> http://xircles.codehaus.org/manage_email
>
>
>
