Repositories

[Steve Ebersole]

I am having no luck defining secondary Maven repositories.  Most JBoss
projects for example will need to simultaneously access the Maven
central repository as well as the JBoss repository.  So I tried the
following:
subprojects {
    ...
    repositories {
        mavenCentral()
        mavenRepo urls: "http://repository.jboss.com/maven2"
    }
    ...
}

I have also tried:
subprojects {
    ...
    repositories {
        mavenRepo urls: "http://localhost:8081/artifactory/repo/"
    }
    ..
}
where that URL is a local instance of artifactory I run on my machine.

I have tried a few other variations as well.  Yet no matter what, my
compilations end up failing because of not being able to find classes
which should be in jars coming from this JBoss repository.  Heck, the
artifacts should already be in my local Maven repository
(~/.m2/repository), though was not sure how/if Gradle interacted with
that.

So am I doing something wrong here?  I thought I was following
http://www.gradle.org/0.8/docs/userguide/userguide_single.html#sec:repositories pretty closely.

--
Steve Ebersole <steve@...>
Hibernate.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Steve Ebersole]

OMG, I actually figured one out on my own!  Yaay :)

So actually, the issue was my misunderstanding of the dependency
configurations.  What I need is a configuration that is used for
compilation, but that is not transitive (similar to provided or optional
in Maven).

I had put them in runtime because in reading
http://www.gradle.org/0.8/docs/userguide/userguide_single.html#sec:java_plugin_and_dependency_management (specifically Table 18.5) I initially thought that runtime did just that.  Re-reading it I misunderstood.  

So instead of:
dependencies {
    ...
    runtime {
        'javassist:javassist:3.9.0.GA',
        'cglib:cglib:2.2',
        ...
    }
}

I did:
configurations {
    provided {
        description = 'Non-transitive compile classpath elements'
        transitive = false
    }
}

dependencies {
    ...
    provided {
        'javassist:javassist:3.9.0.GA',
        'cglib:cglib:2.2',
        ...
    }
}

sourceSets {
    main {
        compileClasspath = configurations.compile +
configurations.provided
    }
}



On Fri, 2009-10-09 at 20:57 -0500, Steve Ebersole wrote:

> I am having no luck defining secondary Maven repositories.  Most JBoss
> projects for example will need to simultaneously access the Maven
> central repository as well as the JBoss repository.  So I tried the
> following:
> subprojects {
>     ...
>     repositories {
>         mavenCentral()
>         mavenRepo urls: "http://repository.jboss.com/maven2"
>     }
>     ...
> }
>
> I have also tried:
> subprojects {
>     ...
>     repositories {
>         mavenRepo urls: "http://localhost:8081/artifactory/repo/"
>     }
>     ..
> }
> where that URL is a local instance of artifactory I run on my machine.
>
> I have tried a few other variations as well.  Yet no matter what, my
> compilations end up failing because of not being able to find classes
> which should be in jars coming from this JBoss repository.  Heck, the
> artifacts should already be in my local Maven repository
> (~/.m2/repository), though was not sure how/if Gradle interacted with
> that.
>
> So am I doing something wrong here?  I thought I was following
> http://www.gradle.org/0.8/docs/userguide/userguide_single.html#sec:repositories pretty closely.
>

--
Steve Ebersole <steve@...>
Hibernate.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[LightGuard]

On Fri, Oct 9, 2009 at 20:33, Steve Ebersole <steve@...> wrote:

> OMG, I actually figured one out on my own!  Yaay :)
>
> So actually, the issue was my misunderstanding of the dependency
> configurations.  What I need is a configuration that is used for
> compilation, but that is not transitive (similar to provided or optional
> in Maven).
>
> I had put them in runtime because in reading
> http://www.gradle.org/0.8/docs/userguide/userguide_single.html#sec:java_plugin_and_dependency_management (specifically Table 18.5) I initially thought that runtime did just that.  Re-reading it I misunderstood.
>
> So instead of:
> dependencies {
>    ...
>    runtime {
>        'javassist:javassist:3.9.0.GA',
>        'cglib:cglib:2.2',
>        ...
>    }
> }
>
> I did:
> configurations {
>    provided {
>        description = 'Non-transitive compile classpath elements'
>        transitive = false
>    }
> }
>
> dependencies {
>    ...
>    provided {
>        'javassist:javassist:3.9.0.GA',
>        'cglib:cglib:2.2',
>        ...
>    }
> }
>
> sourceSets {
>    main {
>        compileClasspath = configurations.compile +
> configurations.provided
>    }
> }
>
>
>
> On Fri, 2009-10-09 at 20:57 -0500, Steve Ebersole wrote:
>> I am having no luck defining secondary Maven repositories.  Most JBoss
>> projects for example will need to simultaneously access the Maven
>> central repository as well as the JBoss repository.  So I tried the
>> following:
>> subprojects {
>>     ...
>>     repositories {
>>         mavenCentral()
>>         mavenRepo urls: "http://repository.jboss.com/maven2"
>>     }
>>     ...
>> }
>>
>> I have also tried:
>> subprojects {
>>     ...
>>     repositories {
>>         mavenRepo urls: "http://localhost:8081/artifactory/repo/"
>>     }
>>     ..
>> }
>> where that URL is a local instance of artifactory I run on my machine.
>>
>> I have tried a few other variations as well.  Yet no matter what, my
>> compilations end up failing because of not being able to find classes
>> which should be in jars coming from this JBoss repository.  Heck, the
>> artifacts should already be in my local Maven repository
>> (~/.m2/repository), though was not sure how/if Gradle interacted with
>> that.
>>
>> So am I doing something wrong here?  I thought I was following
>> http://www.gradle.org/0.8/docs/userguide/userguide_single.html#sec:repositories pretty closely.
>>
> --
> Steve Ebersole <steve@...>
> Hibernate.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>    http://xircles.codehaus.org/manage_email
>
>
>

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):

 21 repositories {
 22     mavenCentral()
 23     mavenRepo urls: 'http://repository.jboss.org/maven2'
 24 }

I'd have to see what you're doing differently there Steve, maybe we should put this up on svn or github or something :)

--
Jason Porter
Real Programmers think better when playing Adventure or Rogue.

PGP key id: 926CCFF5
PGP fingerprint: 64C2 C078 13A9 5B23 7738 F7E5 1046 C39B 926C CFF5
PGP key available at: keyserver.net, pgp.mit.edu

[Steve Ebersole]

On Fri, 2009-10-09 at 20:48 -0600, lightguard.jp@... 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...


--
Steve Ebersole <steve@...>
Hibernate.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

Steve Ebersole wrote:

On Fri, 2009-10-09 at 20:48 -0600, lightguard.jp@... 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 :)

  

Ideally, you would be able to do something like this:

configurations {
    provided {
        transitive = true
    }
    compile {
        extendsFrom provided
    }
}

dependencies {
    provided 'some-transitive-dependency'
    compile 'some-non-transitive-dependency'
}

so that any dependency added to compile is not transitive, and any dependency added to provided is transitive.

Unfortunately, the 'transitive' flag from compile wins when it is resolved, so every dependency will be non transitive.

We can add the following hack somewhere in the build file to get the behaviour we need:

afterEvaluate {
    configurations.compile.transitive = true
    configurations.compile.dependencies.each { it.transitive = false }
    configurations.provided.dependencies.each { it.transitive = true }
}


I think the current behaviour of the transitive flag could be improved. Perhaps we should change things so that the configuration's transitive flag simply works as the default value for the transitive flag of the dependencies in the configuration.

[Steve Ebersole]

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?  And What, if any, effect
transitive has on that?

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.

Thanks...



On Mon, 2009-10-12 at 11:02 -0500, Steve Ebersole wrote:

> On Fri, 2009-10-09 at 20:48 -0600, lightguard.jp@... 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...
>
>

--
Steve Ebersole <steve@...>
Hibernate.org


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

[Adam Murdoch-2]

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, lightguard.jp@... 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