On Jan 26, 2009, at 10:09 AM, Tom Eyckmans wrote:
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
}
In Ivy one configuration can be used both for assigning dependencies
to it and assigning artifacts to publish. I think this makes a lot of
sense, in particular if the project constitutes a library to be used
by other projects. The other project refers to a configuration of the
project, which describes a set of artifacts and a set of dependencies.
There are also many use cases where this is not important. Where you
will create configurations just for publishing or just for resolving
dependencies. But our design wouldn't make this more complicated. But
it means one thing for your proposal above. That is the configurations
have to be defined separately from the dependencies and
upload(publish) context.
I'm not sure yet what is a good way to integrate artifacts and archives.
The notation (which is the same as I have used in the first email)
artifacts {
examples jar() {...}
}
look pretty neat. But often the closure of the jar will be a biggy.
I'm not sure how nice this reads in real life.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
