Adam Murdoch wrote:
Steve Appling wrote:
I would love to change this name. I did not come from an Ivy
background and have always felt this was awkward.
I have also always felt that using configurations to store paths and
to specify a distribution archive were two very different uses that
didn't belong together. I would like to see the archive part pulled
out into another concept.
I agree. I think we have 2 separate concepts here: a project has
dependencies, and a project has publications.
Dependencies are artifacts produced outside the project, which are used
by the project in some way, whether that is in the build script, or at
compile time, or execution time, or whatever.
Publications are artifacts produced by the project, and which are made
available as dependencies for other projects.
An artifact may be an archive, or an xsl file, or an image file, or a
license file, or a report, or some javadoc, or whatever. It's just a
file shared between projects.
To me, the core of configurations are named dependencies. I like:
dependencyNames {
compile
openAPI
}
dependencies {
compile 'commons-io:commons-io:1.4'
}
I think "paths" are a little too generic. And paths.compile.asPath
seems a little strange :)
I think we should merge what is currently configurations {} into what is
dependencies { }, as John has suggested.
I prefer the implicit creation. I really don't buy the typo argument
against it. I can't say I've ever had it happen in practise. Even if it
does, the problem lasts about as long as it takes for Gradle to get to
the compile task.
So, I think we should have something like:
dependencies {
compile { transitive = false } // what we have in configurations { }
compile {
transitive = false
dependency 'some-dep' // allow dependencies to be added directly
to a Configuration
dependency module('some-module') { ... }
}
compile 'some-dep' // this is simply a shortcut for compile {
dependency('some-dep') }
}
I would model the elements of the dependencies container as composite
dependencies, that is, each element is a Dependency to which other
Dependency instances can be added. We might call it DependencySet or
NamedDependency or CompositeDependency or DependencyConfiguration or
something. We could get rid of configuration inheritence by allowing
composite dependencies to be added to each other.
As for dependencies {}, I think we should also merge configurations { }
into artifacts { }, and rename it to publications { }
publications {
default {
artifact myJar
}
default myJar // this is a shortcut for default { artifact(myJar) }
}
Similar to Dependency, we would have a Publication type, and number of
implementations. One would be a single file. Another would be a
composite Publication to which other Publications can be added.
When a composite publication is published, the runtime dependencies to
be included in the dependency descriptor are specified by the
publications it contains. In the example above, when the 'default'
publication is published, we know from how myJar is built, that it needs
all the dependencies declared in the (incoming) 'runtime' dependency, so
we just copy the dependencies across to the publication.
+1 to all of this - I think this is much better.
--
Steve Appling
Automated Logic Research Team
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
