On Feb 1, 2009, at 1:45 PM, Hans Dockter wrote:
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.
Besides the fact that we also have archives which are not supposed to
be published and shouldn't be assigned to any configuration. And we
should have the concept of a configuration where archives to be
published are automatically assigned to.
- Hans
--
Hans Dockter
Gradle Project lead
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
