Need minimal command/code to resolve/retrieve dependencies, nothing else

classic Classic list List threaded Threaded
20 messages Options
Reply | Threaded
Open this post in threaded view
|

Need minimal command/code to resolve/retrieve dependencies, nothing else

Carlton Brown
Hi,

I'm an Ivy user doing some exploratory testing to evaluate Gradle.  I just want to see dependency resolution/retrieval in action, nothing else right now.   After I've defined a dependency and a resolver in my build.gradle, what command do I issue to cause a resolve to occur?   Following that, what do I need to do to cause an artifact retrieve to occur?

Apologies if I'm expressing this too much in Ant/Ivy terminology, but that's the context I'm coming from.   Please feel free to correct my perspective.

Thanks,
Carlton
Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Philip Crotwell
I think
gradle dependencies
will do that.

Philip

On Mon, Sep 26, 2011 at 11:28 AM, Carlton Brown <[hidden email]> wrote:

> Hi,
> I'm an Ivy user doing some exploratory testing to evaluate Gradle.  I just
> want to see dependency resolution/retrieval in action, nothing else right
> now.   After I've defined a dependency and a resolver in my build.gradle,
> what command do I issue to cause a resolve to occur?   Following that, what
> do I need to do to cause an artifact retrieve to occur?
> Apologies if I'm expressing this too much in Ant/Ivy terminology, but that's
> the context I'm coming from.   Please feel free to correct my perspective.
> Thanks,
> Carlton

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Carlton Brown
It does not appear to be the case.   It looks like 'gradle dependencies' only displays the dependency definitions, it does not actually retrieve them into the .gradle dir.

On Mon, Sep 26, 2011 at 11:38 AM, Philip Crotwell <[hidden email]> wrote:
I think
gradle dependencies
will do that.

Philip

On Mon, Sep 26, 2011 at 11:28 AM, Carlton Brown <[hidden email]> wrote:
> Hi,
> I'm an Ivy user doing some exploratory testing to evaluate Gradle.  I just
> want to see dependency resolution/retrieval in action, nothing else right
> now.   After I've defined a dependency and a resolver in my build.gradle,
> what command do I issue to cause a resolve to occur?   Following that, what
> do I need to do to cause an artifact retrieve to occur?
> Apologies if I'm expressing this too much in Ant/Ivy terminology, but that's
> the context I'm coming from.   Please feel free to correct my perspective.
> Thanks,
> Carlton

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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Luke Daley-2
In reply to this post by Carlton Brown

On 26/09/2011, at 4:28 PM, Carlton Brown wrote:

> I'm an Ivy user doing some exploratory testing to evaluate Gradle.  I just want to see dependency resolution/retrieval in action, nothing else right now.   After I've defined a dependency and a resolver in my build.gradle, what command do I issue to cause a resolve to occur?   Following that, what do I need to do to cause an artifact retrieve to occur?

Gradle uses the concept of a “configuration” to contain dependencies.

http://gradle.org/current/docs/javadoc/org/gradle/api/artifacts/Configuration.html

You'll see that a Configuration is a FileCollection, which is a Gradle type for bunch of files. So the easiest way to do a resolve is to ask the FileCollection for its File objects <http://gradle.org/current/docs/javadoc/org/gradle/api/file/FileCollection.html#getFiles()>

Here's a script you could use:

apply plugin: "java"

repositories {
        mavenCentral()
}

dependencies {
        compile 'commons-lang:commons-lang:2.6'
}

task doTestResolve << {
        configurations.compile.files.each { println "resolved dependency: $it" }
}

task doTestRetrieve(type: Copy) {
        from configurations.compile
        into "myDependencies"
        eachFile {
            println "retrieving dependency: $it.name"
        }
}


Depending on what you were trying to achieve, you might do some things slightly differently there in a real world scenario but they are minor things and aren't important if you just want to play with dependency management.

> Apologies if I'm expressing this too much in Ant/Ivy terminology, but that's the context I'm coming from.   Please feel free to correct my perspective.

I'm not sure my understanding of the terms with Ivy is correct so what's above may not map to what you had in mind.

In Gradle, you simply declares what dependencies need to be part of a configuration and when those files are requested Gradle will make them available (or die trying).

--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com


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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Carlton Brown
Thanks Luke, that will get me started.

Does everyone have to write these few lines of code in their Gradle build, or is there some other mechanism that implicitly causes a resolve/retrieve to happen?

Also, I notice that Gradle does not accept a version string of 'latest.integration' which in Ivy would signify the latest revision published with a status of 'integration'.  Is Gradle aware of Ivy statuses at all, or does it have some analogous function?

On Mon, Sep 26, 2011 at 12:09 PM, Luke Daley <[hidden email]> wrote:

On 26/09/2011, at 4:28 PM, Carlton Brown wrote:

> I'm an Ivy user doing some exploratory testing to evaluate Gradle.  I just want to see dependency resolution/retrieval in action, nothing else right now.   After I've defined a dependency and a resolver in my build.gradle, what command do I issue to cause a resolve to occur?   Following that, what do I need to do to cause an artifact retrieve to occur?

Gradle uses the concept of a “configuration” to contain dependencies.

http://gradle.org/current/docs/javadoc/org/gradle/api/artifacts/Configuration.html

You'll see that a Configuration is a FileCollection, which is a Gradle type for bunch of files. So the easiest way to do a resolve is to ask the FileCollection for its File objects <http://gradle.org/current/docs/javadoc/org/gradle/api/file/FileCollection.html#getFiles()>

Here's a script you could use:

apply plugin: "java"

repositories {
       mavenCentral()
}

dependencies {
       compile 'commons-lang:commons-lang:2.6'
}

task doTestResolve << {
       configurations.compile.files.each { println "resolved dependency: $it" }
}

task doTestRetrieve(type: Copy) {
       from configurations.compile
       into "myDependencies"
       eachFile {
           println "retrieving dependency: $it.name"
       }
}


Depending on what you were trying to achieve, you might do some things slightly differently there in a real world scenario but they are minor things and aren't important if you just want to play with dependency management.

> Apologies if I'm expressing this too much in Ant/Ivy terminology, but that's the context I'm coming from.   Please feel free to correct my perspective.

I'm not sure my understanding of the terms with Ivy is correct so what's above may not map to what you had in mind.

In Gradle, you simply declares what dependencies need to be part of a configuration and when those files are requested Gradle will make them available (or die trying).

--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com


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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Luke Daley-2

On 26/09/2011, at 7:11 PM, Carlton Brown wrote:

Thanks Luke, that will get me started.

Does everyone have to write these few lines of code in their Gradle build, or is there some other mechanism that implicitly causes a resolve/retrieve to happen?

It's a completely contrived example, you wouldn't write this kind of thing.

If you were building a java project that needed to compile against commons-lang, all you would need to do is: 

apply plugin: "java"

repositories {
       mavenCentral()
}

dependencies {
       compile 'commons-lang:commons-lang:2.6'
}

The “java” plugin wires the model together in such a way that the compile classpath for the project ends up being the “compile” configuration (which is like a collection of files). When the files are needed, e.g. at compile time, Gradle will implicitly perform the resolve and make the files available to the compiler. As far as the compile machinery is concerned, it's just receiving a bunch of files and the resolution happens seamlessly.

Also, I notice that Gradle does not accept a version string of 'latest.integration' which in Ivy would signify the latest revision published with a status of 'integration'.  Is Gradle aware of Ivy statuses at all, or does it have some analogous function?

What kind of repository/resolver are you using?

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Carlton Brown
On Mon, Sep 26, 2011 at 2:31 PM, Luke Daley <[hidden email]> wrote:


The “java” plugin wires the model together in such a way that the compile classpath for the project ends up being the “compile” configuration (which is like a collection of files). When the files are needed, e.g. at compile time, Gradle will implicitly perform the resolve and make the files available to the compiler. As far as the compile machinery is concerned, it's just receiving a bunch of files and the resolution happens seamlessly.

What if I need to do it explicitly?   Say I have a configuration called 'hammer' and a task also called 'hammer', how do I code it so that I have hammer dependencies on hammer's classpath at hammertime?

 

Also, I notice that Gradle does not accept a version string of 'latest.integration' which in Ivy would signify the latest revision published with a status of 'integration'.  Is Gradle aware of Ivy statuses at all, or does it have some analogous function?

What kind of repository/resolver are you using?

HTTP (Artifactory). 
Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Luke Daley-2

On 26/09/2011, at 7:40 PM, Carlton Brown wrote:

On Mon, Sep 26, 2011 at 2:31 PM, Luke Daley <[hidden email]> wrote:


The “java” plugin wires the model together in such a way that the compile classpath for the project ends up being the “compile” configuration (which is like a collection of files). When the files are needed, e.g. at compile time, Gradle will implicitly perform the resolve and make the files available to the compiler. As far as the compile machinery is concerned, it's just receiving a bunch of files and the resolution happens seamlessly.

What if I need to do it explicitly?   Say I have a configuration called 'hammer' and a task also called 'hammer', how do I code it so that I have hammer dependencies on hammer's classpath at hammer time?

You still wouldn't need to do it explicitly. What you would want is to “wire” the configuration to the property of the task that specifies the compile time classpath. Whether it's a configuration where the files come from a remote repository or is some other kind of collection of files is irrelevant. 

There is a key difference between Gradle and Ivy in that Gradle has a much richer model and things are less direct. This richer model enables Gradle to do a lot of work for you.

So basically, you are trying to find out how to do “X” that you are used to doing with Ivy but the same concept does not transfer in this new world.

Also, I notice that Gradle does not accept a version string of 'latest.integration' which in Ivy would signify the latest revision published with a status of 'integration'.  Is Gradle aware of Ivy statuses at all, or does it have some analogous function?
 

What kind of repository/resolver are you using?

HTTP (Artifactory). 

How do you declare the repository in your Gradle build?

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Carlton Brown


On Mon, Sep 26, 2011 at 2:50 PM, Luke Daley <[hidden email]> wrote:

There is a key difference between Gradle and Ivy in that Gradle has a much richer model and things are less direct. This richer model enables Gradle to do a lot of work for you.

So basically, you are trying to find out how to do “X” that you are used to doing with Ivy but the same concept does not transfer in this new world.


I am just trying to see how jars in configuration X are assigned to the classpath of task X, when X is not named 'compile'.   This would illustrate for me how the wiring works, so that I know how to set up the right conditions for indirect behavior for non-default inputs.   
 

Also, I notice that Gradle does not accept a version string of 'latest.integration' which in Ivy would signify the latest revision published with a status of 'integration'.  Is Gradle aware of Ivy statuses at all, or does it have some analogous function?
 

What kind of repository/resolver are you using?

HTTP (Artifactory). 

How do you declare the repository in your Gradle build?

It looks like this (which could be totally wrong)

  ivy {
    name= 'libs-trunk'
    userName = 'ivyuser'
    password = 'ivypass'
    artifactPattern '<a href="http://my.server/aritfactory/libs-trunk/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]">http://my.server/aritfactory/libs-trunk/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]'
  }
 
Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Luke Daley-2

On 26/09/2011, at 8:35 PM, Carlton Brown wrote:

On Mon, Sep 26, 2011 at 2:50 PM, Luke Daley <[hidden email]> wrote:

There is a key difference between Gradle and Ivy in that Gradle has a much richer model and things are less direct. This richer model enables Gradle to do a lot of work for you.

So basically, you are trying to find out how to do “X” that you are used to doing with Ivy but the same concept does not transfer in this new world.


I am just trying to see how jars in configuration X are assigned to the classpath of task X, when X is not named 'compile'.   This would illustrate for me how the wiring works, so that I know how to set up the right conditions for indirect behavior for non-default inputs.   

Tasks in general don't have a classpath. Something like a compile task would though so I'll assume that's what you are talking about.



So you if all you want to do is wire a configuration to a compile task, you would do:

configurations {
myCustomConfiguration // creates the configuration
}

dependencies {
myCustomConfiguration "some-org:some-artifact:1.0"
}

task customCompile(type: Compile) {
// other task configuration
classpath = configurations.myCustomConfiguration
}

 

Also, I notice that Gradle does not accept a version string of 'latest.integration' which in Ivy would signify the latest revision published with a status of 'integration'.  Is Gradle aware of Ivy statuses at all, or does it have some analogous function?
 

What kind of repository/resolver are you using?

HTTP (Artifactory). 

How do you declare the repository in your Gradle build?

It looks like this (which could be totally wrong)

  ivy {
    name= 'libs-trunk'
    userName = 'ivyuser'
    password = 'ivypass'
    artifactPattern '<a href="http://my.server/aritfactory/libs-trunk/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]">http://my.server/aritfactory/libs-trunk/[organisation]/[module]/[revision]/[artifact]-[revision](-[classifier]).[ext]'
  }

Unfortunately, you are hitting http://issues.gradle.org/browse/GRADLE-1789. This is high on the priority list for 1.0.

There is a workaround which is currently not listed on that ticket, but will be very soon.

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Carlton Brown
Thank you for all of your responses.

On Mon, Sep 26, 2011 at 5:49 PM, Luke Daley <[hidden email]> wrote:

On 26/09/2011, at 8:35 PM, Carlton Brown wrote:

On Mon, Sep 26, 2011 at 2:50 PM, Luke Daley <[hidden email]> wrote:

There is a key difference between Gradle and Ivy in that Gradle has a much richer model and things are less direct. This richer model enables Gradle to do a lot of work for you.

So basically, you are trying to find out how to do “X” that you are used to doing with Ivy but the same concept does not transfer in this new world.


I am just trying to see how jars in configuration X are assigned to the classpath of task X, when X is not named 'compile'.   This would illustrate for me how the wiring works, so that I know how to set up the right conditions for indirect behavior for non-default inputs.   

Tasks in general don't have a classpath. Something like a compile task would though so I'll assume that's what you are talking about.



So you if all you want to do is wire a configuration to a compile task, you would do:

configurations {
myCustomConfiguration // creates the configuration
}

dependencies {
myCustomConfiguration "some-org:some-artifact:1.0"
}

task customCompile(type: Compile) {
// other task configuration
classpath = configurations.myCustomConfiguration
}

 

Also, I notice that Gradle does not accept a version string of 'latest.integration' which in Ivy would signify the latest revision published with a status of 'integration'.  Is Gradle aware of Ivy statuses at all, or does it have some analogous function?
 

What kind of repository/resolver are you using?

HTTP (Artifactory). 

How do you declare the repository in your Gradle build?

It looks like this (which could be totally wrong)

  ivy {
    name= 'libs-trunk'
    userName = 'ivyuser'
    password = 'ivypass'
  }

Unfortunately, you are hitting http://issues.gradle.org/browse/GRADLE-1789. This is high on the priority list for 1.0.

There is a workaround which is currently not listed on that ticket, but will be very soon.


-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com


Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Carlton Brown
In reply to this post by Luke Daley-2
One more question on the 'retrieve' code... I notice that the jars copied by Gradle have revision numbers in the filename.   Is there a way to access just the jar name without the revision number?   In Ivy this would be a simple matter of specifying the right retrieval pattern to the retrieve task.

On Mon, Sep 26, 2011 at 12:09 PM, Luke Daley <[hidden email]> wrote:

On 26/09/2011, at 4:28 PM, Carlton Brown wrote:

> I'm an Ivy user doing some exploratory testing to evaluate Gradle.  I just want to see dependency resolution/retrieval in action, nothing else right now.   After I've defined a dependency and a resolver in my build.gradle, what command do I issue to cause a resolve to occur?   Following that, what do I need to do to cause an artifact retrieve to occur?

Gradle uses the concept of a “configuration” to contain dependencies.

http://gradle.org/current/docs/javadoc/org/gradle/api/artifacts/Configuration.html

You'll see that a Configuration is a FileCollection, which is a Gradle type for bunch of files. So the easiest way to do a resolve is to ask the FileCollection for its File objects <http://gradle.org/current/docs/javadoc/org/gradle/api/file/FileCollection.html#getFiles()>

Here's a script you could use:

apply plugin: "java"

repositories {
       mavenCentral()
}

dependencies {
       compile 'commons-lang:commons-lang:2.6'
}

task doTestResolve << {
       configurations.compile.files.each { println "resolved dependency: $it" }
}

task doTestRetrieve(type: Copy) {
       from configurations.compile
       into "myDependencies"
       eachFile {
           println "retrieving dependency: $it.name"
       }
}


Depending on what you were trying to achieve, you might do some things slightly differently there in a real world scenario but they are minor things and aren't important if you just want to play with dependency management.

> Apologies if I'm expressing this too much in Ant/Ivy terminology, but that's the context I'm coming from.   Please feel free to correct my perspective.

I'm not sure my understanding of the terms with Ivy is correct so what's above may not map to what you had in mind.

In Gradle, you simply declares what dependencies need to be part of a configuration and when those files are requested Gradle will make them available (or die trying).

--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com


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

   http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Luke Daley-2

On 27/09/2011, at 8:33 PM, Carlton Brown wrote:

One more question on the 'retrieve' code... I notice that the jars copied by Gradle have revision numbers in the filename.   Is there a way to access just the jar name without the revision number?   In Ivy this would be a simple matter of specifying the right retrieval pattern to the retrieve task.

You'd do this at the level of files in Gradle, not at the Ivy level.

task doTestRetrieve(type: Copy) {
       from configurations.compile
       into "myDependencies"
       rename "(.+)-.+\\.(\w+)", '$1.$2'
       eachFile {
           println "retrieving dependency: $it.name"
       }
}

Or if regexes aren't your thing there are other ways to do the rename.

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Carlton Brown
What are the other ways?   I don't mind regex when necessary, and I know that duplicating ivy is not the goal of this project, but it would really make sense to have a more specialized abstraction for dealing with artifacts than just treating them as undifferentiated files.

On Tue, Sep 27, 2011 at 4:34 PM, Luke Daley <[hidden email]> wrote:

On 27/09/2011, at 8:33 PM, Carlton Brown wrote:

One more question on the 'retrieve' code... I notice that the jars copied by Gradle have revision numbers in the filename.   Is there a way to access just the jar name without the revision number?   In Ivy this would be a simple matter of specifying the right retrieval pattern to the retrieve task.

You'd do this at the level of files in Gradle, not at the Ivy level.

task doTestRetrieve(type: Copy) {
       from configurations.compile
       into "myDependencies"
       rename "(.+)-.+\\.(\w+)", '$1.$2'
       eachFile {
           println "retrieving dependency: $it.name"
       }
}

Or if regexes aren't your thing there are other ways to do the rename.

-- 

Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com


Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Luke Daley-2

On 27/09/2011, at 9:42 PM, Carlton Brown wrote:

What are the other ways?   I don't mind regex when necessary,


You can give rename a closure and cut the name up however you like.

and I know that duplicating ivy is not the goal of this project, but it would really make sense to have a more specialized abstraction for dealing with artifacts than just treating them as undifferentiated files.

That's proven to be not a very common need, and this kind of abstraction makes using different kinds of artifacts and artifact sources possible.

It's also not about not duplicating Ivy, it's about being a more general tool. Ivy is an implementation detail and over time less Ivy-isms will be at the surface.


I think what you might be after is a way to create a kind of mini repository locally inside your build. Most users never need to do this but it does pop up sometimes. At the moment there is no easy way to do this in a way that includes all the metadata. It is easy to do for just the artifacts though.

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Carlton Brown
In reply to this post by Carlton Brown
Or to step back to a higher level... how do Gradle users working in an IDE deal with their classpath continually breaking because their jar filenames are changing when newer versions are resolved? 

On Tue, Sep 27, 2011 at 4:42 PM, Carlton Brown <[hidden email]> wrote:
What are the other ways?   I don't mind regex when necessary, and I know that duplicating ivy is not the goal of this project, but it would really make sense to have a more specialized abstraction for dealing with artifacts than just treating them as undifferentiated files.


On Tue, Sep 27, 2011 at 4:34 PM, Luke Daley <[hidden email]> wrote:

On 27/09/2011, at 8:33 PM, Carlton Brown wrote:

One more question on the 'retrieve' code... I notice that the jars copied by Gradle have revision numbers in the filename.   Is there a way to access just the jar name without the revision number?   In Ivy this would be a simple matter of specifying the right retrieval pattern to the retrieve task.

You'd do this at the level of files in Gradle, not at the Ivy level.

task doTestRetrieve(type: Copy) {
       from configurations.compile
       into "myDependencies"
       rename "(.+)-.+\\.(\w+)", '$1.$2'
       eachFile {
           println "retrieving dependency: $it.name"
       }
}

Or if regexes aren't your thing there are other ways to do the rename.

-- 

Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com



Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Luke Daley-2

On 27/09/2011, at 9:49 PM, Carlton Brown wrote:

Or to step back to a higher level... how do Gradle users working in an IDE deal with their classpath continually breaking because their jar filenames are changing when newer versions are resolved? 

You rerun the tasks to generate the classpath metadata.

In the future this won't even be necessary as popular IDEs are starting to take the approach of querying the Gradle model programatically, so this kind of metadata will not be needed.

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Carlton Brown
In reply to this post by Luke Daley-2
I'll make this correction on the list so others can see it... but there are 2 issues with this retrieve code... first, when defining the regexp, Groovy seems to choke on the backslash of the \w string..  I had to use the tilde constructor to make it work.    Also the regexp was too naive to cover all the dependency variations that exist in the wild.   Here's what I got to work:

task retrieve(type: Copy) {
       libsDir = "libs-gradle/compile"
       delete libsDir
       from configurations.compile
       into libsDir
       rename ~/^([a-z0-9-_]+[a-z0-9])-[0-9]+\..+\.(.+)$/, '$1.$2'
       eachFile {
           println "retrieved: $it.name"
       }
}

The above code will simplify every naming convention I know of, but it does not account for retrieval conflicts.  For example, Ivy would display a warning if 2 different jars were simplified to the same name.

On Tue, Sep 27, 2011 at 4:34 PM, Luke Daley <[hidden email]> wrote:

On 27/09/2011, at 8:33 PM, Carlton Brown wrote:

One more question on the 'retrieve' code... I notice that the jars copied by Gradle have revision numbers in the filename.   Is there a way to access just the jar name without the revision number?   In Ivy this would be a simple matter of specifying the right retrieval pattern to the retrieve task.

You'd do this at the level of files in Gradle, not at the Ivy level.

task doTestRetrieve(type: Copy) {
       from configurations.compile
       into "myDependencies"
       rename "(.+)-.+\\.(\w+)", '$1.$2'
       eachFile {
           println "retrieving dependency: $it.name"
       }
}

Or if regexes aren't your thing there are other ways to do the rename.

-- 

Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com


Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Luke Daley-2

On 29/09/2011, at 5:27 PM, Carlton Brown wrote:

I'll make this correction on the list so others can see it... but there are 2 issues with this retrieve code... first, when defining the regexp, Groovy seems to choke on the backslash of the \w string..  I had to use the tilde constructor to make it work.    Also the regexp was too naive to cover all the dependency variations that exist in the wild.   Here's what I got to work:

task retrieve(type: Copy) {
       libsDir = "libs-gradle/compile"
       delete libsDir
       from configurations.compile
       into libsDir
       rename ~/^([a-z0-9-_]+[a-z0-9])-[0-9]+\..+\.(.+)$/, '$1.$2'
       eachFile {
           println "retrieved: $it.name"
       }
}

The above code will simplify every naming convention I know of, but it does not account for retrieval conflicts.  For example, Ivy would display a warning if 2 different jars were simplified to the same name.

Instead of using the delete, you should turn this into a sync task:

task retrieve(type: Sync) {
       libsDir = "libs-gradle/compile"
       from configurations.compile
       into libsDir
       rename ~/^([a-z0-9-_]+[a-z0-9])-[0-9]+\..+\.(.+)$/, '$1.$2'
       eachFile {
           println "retrieved: $it.name"
       }
}

Sync makes the destination dir exactly match the source, so will remove any old files.

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com

Reply | Threaded
Open this post in threaded view
|

Re: Need minimal command/code to resolve/retrieve dependencies, nothing else

Carlton Brown
Good idea, thanks.

On Thu, Sep 29, 2011 at 12:31 PM, Luke Daley <[hidden email]> wrote:

On 29/09/2011, at 5:27 PM, Carlton Brown wrote:

I'll make this correction on the list so others can see it... but there are 2 issues with this retrieve code... first, when defining the regexp, Groovy seems to choke on the backslash of the \w string..  I had to use the tilde constructor to make it work.    Also the regexp was too naive to cover all the dependency variations that exist in the wild.   Here's what I got to work:

task retrieve(type: Copy) {
       libsDir = "libs-gradle/compile"
       delete libsDir
       from configurations.compile
       into libsDir
       rename ~/^([a-z0-9-_]+[a-z0-9])-[0-9]+\..+\.(.+)$/, '$1.$2'
       eachFile {
           println "retrieved: $it.name"
       }
}

The above code will simplify every naming convention I know of, but it does not account for retrieval conflicts.  For example, Ivy would display a warning if 2 different jars were simplified to the same name.

Instead of using the delete, you should turn this into a sync task:

task retrieve(type: Sync) {
       libsDir = "libs-gradle/compile"
       from configurations.compile
       into libsDir
       rename ~/^([a-z0-9-_]+[a-z0-9])-[0-9]+\..+\.(.+)$/, '$1.$2'
       eachFile {
           println "retrieved: $it.name"
       }
}

Sync makes the destination dir exactly match the source, so will remove any old files.

-- 
Luke Daley
Principal Engineer, Gradleware 
http://gradleware.com