Steve Ebersole wrote:
Ok, I apologize. It seems I am not using the correct terms here.
What I am really concerned with is the importing of dependencies and the
exporting of dependencies and how transitivity is applied for each.
"Direct dependencies" or "first level dependencies" are imported merely
by the fact that they are specified in the dependencies section. The
transitive property for each dependency (defaulted from the
configuration to which it is added) defines whether that dependency's
dependencies are also imported.
In terms of exporting, there seems to be some confusion on how exactly
this works. So I'd like to first get clarification of this before I ask
anymore unintentionally off-topic questions :) So can anyone help
qualify exactly how dependencies are exported?
Just to clarify, to me, to 'export' a dependency means to include it in
the generated project descriptor (pom.xml or ivy.xml).
For the ivy.xml:
- Each configuration is included in the ivy.xml
- The configuration's transitive flag is ignored and always set to 'true'
- For each configuration, each first-level dependency is included in the
ivy.xml
- The transitive flag of the dependency is copied across
You can intercept and transform the ivy module descriptor before it is
written to file, but its not particularly convenient to do so.
I think the transitive behaviour is a little broken.
For the pom.xml:
- Each configuration with a scope mapping is included in the pom.xml
- The following configurations have a scope mapping by default:
compile, runtime, testCompile, testRuntime
- The following configurations have a scope mapping when you use the
war plugin: providedCompile and providedRuntime
- You can add your own mapping: conf2ScopeMappings.addMapping(100,
configurations.myConfig, 'provided')
- For each included configuration, each first-level dependency is
included in the pom.xml
- Transitive is always true
So, you have some control over how dependencies are exported, by placing
them into different configurations.
And What, if any, effect
transitive has on that?
None.
Below, what I really need is a way to say that a given dependency is
transitive in terms of its importing, but that it should not be
exported.
If you only care about the pom, you can do this by adding the
dependencies to a configuration with no scope mapping. You would need a
configuration for each combination of (import-transitive, exported) you
need.
For example, say we want to add some transitive, non-exported
dependencies to the compile configuration:
configurations {
optional
compile { extendsFrom optional }
}
dependencies {
optional 'some-optional-dep', 'some-other-optional-dep'
compile 'some-dep'
}
// A work-around for the not-quite-right behaviour of
configuration.transitive = false
afterEvaluate {
compile.transitive = true
compile.dependencies.each { it.transitive = false }
}
I think for the 0.9 release, we want to end up with a DSL which lets you
specify independently for a dependency its transitivity and visibility
(ie whether they are exported). We also want some way to specify these
things for a group of dependencies. We might also provide some way to
inline transitive dependencies in the generated descriptor.
How this DSL might look, I'm not sure yet.
Thanks...
On Mon, 2009-10-12 at 11:02 -0500, Steve Ebersole wrote:
On Fri, 2009-10-09 at 20:48 -0600, [email protected] wrote:
Hm. The compile configuration is already non-transitive, what you did should
have worked (and I've had it work just for me in the past as well):
Ok, just a mis-guess then coming from Maven that compile would be transitive.
Its one or the other, I just guessed wrong. Section 18.4 describes that.
But regardless, I need both sets : compile-time deps that are transitive
as well as compile-time deps that are non-transitive. So I cannot
simply turn on transitivity of the compile configuration here like shown
in the docs. So what is the best way to do that? I understand I could
in fact specify transitivity on each dependency, but I prefer the
grouping approach (here are the set of transitive compile-time
dependencies) from a readability perspective. Obviously if such an
approach (split config, etc) causes more difficulty elsewhere, that
could sawy me too :)
I'd have to see what you're doing differently there Steve, maybe we should put
this up on svn or github or something :)
I'll set up a branch...
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
