retrieveLibs command to support switching to flatDir

[Helmut Denk]

hi gradle,

one thing, that could be useful IMO
is a retrieve-command that supports
switching from ivy/maven-repositories
to flatDir.

in ant+ivy it is like this:

*** snip ***
ivy.retrieve.pattern=${lib.dir}/[conf]/[artifact].[ext]

<ivy:retrieve pattern="${ivy.retrieve.pattern}"/> 
*** snap ***

the default-behaviour of a command 'gradle retrieveLibs'
would fetch dependent artefacts into the /lib dir so that
a switch to:

repositories {
    flatDir(dirs: file('lib'))
}  

can be done without manually copying files.

i have such a usecase a second time now.
that's why i think it's worth a note here.

or is there a better/easier way to do this ?

have a successful day

[Helmut Denk]

correction: the ivy.retrieve.pattern for flatDir
must be like this:

ivy.retrieve.pattern=lib/[artifact]-[revision].[ext]

Helmut Denk wrote:

*** snip ***
ivy.retrieve.pattern=${lib.dir}/[conf]/[artifact].[ext]

<ivy:retrieve pattern="${ivy.retrieve.pattern}"/> 
*** snap ***

[Helmut Denk]

for the interested user ...
one way to do this is:

task retrieveRuntimeLibs << {
    Set files = configurations.runtime.resolve()
    ant {
        files.each {
            copy(file: it, todir: 'runtimeLibs')
        }
    }
}

[hdockter]

On Jun 11, 2009, at 5:31 AM, Helmut Denk wrote:

>
> hi gradle,
>
> one thing, that could be useful IMO
> is a retrieve-command that supports
> switching from ivy/maven-repositories
> to flatDir.
>
> in ant+ivy it is like this:
>
>
> *** snip ***
> ivy.retrieve.pattern=${lib.dir}/[conf]/[artifact].[ext]
>
> <ivy:retrieve pattern="${ivy.retrieve.pattern}"/>
> *** snap ***
>
>
> the default-behaviour of a command 'gradle retrieveLibs'
> would fetch dependent artefacts into the /lib dir so that
> a switch to:
>
>
> repositories {
>    flatDir(dirs: file('lib'))
> }

One way of solving this is to define a rule with the pattern:  
retrieve<dirname>
This would copy the testRuntime configuration into <dirname>.

Two future features would make this more powerful.
- Make it easy to create custom task types (which would be instatiated  
by the rule)
- Make it possible to set a task property via the command line (e.g.  
for changing the configuration).

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


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

    http://xircles.codehaus.org/manage_email

[hdockter]

On Jun 13, 2009, at 7:40 AM, Helmut Denk wrote:

>
> for the interested user ...
> one way to do this is:
>
>
> task retrieveRuntimeLibs << {
>    Set files = configurations.runtime.resolve()
>    ant {
>        files.each {
>            copy(file: it, todir: 'runtimeLibs')
>        }
>    }
> }

In trunk you can write:

task retrieveRuntimeLibs << {
    copy {
       from configurations.runtime.files
       into 'runtimeLibs'
    }
}

With 0.7 you can also specify filters based on dependency properties:

task retrieveRuntimeLibs << {
    copy {
       from configurations.runtime.files { dep -> dep.group =  
'something' }
       into 'runtimeLibs'
    }
}

In trunk there is also the feature to copy artifacts to necessarily tp  
a name they have in the local repository, but based on the properties  
of the artifact object.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org


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

    http://xircles.codehaus.org/manage_email

[Philip Crotwell]

Hi

Is there a way to distinguish between multiproject dependencies and
remote jar dependencies? For example in
gradle/src/samples/java/multiproject/services/webservice
the dependencies look like:

dependencies {
    compile project(':shared'),
'commons-collections:commons-collections:3.2@jar',
'commons-io:commons-io:1.2', 'commons-lang:commons-lang:2.4@jar'
    compile project(path: ':api', configuration: 'spi')
    runtime project(':api')
}


then the below copy fails if the api subproject has not yet been
built, which is not what you want if you are just trying to get all
remote dependencies downloaded so you can work "offline". Ideally I
suppose you would want to download all remote jar dependencies and
then run the "retrieveRuntimeLibs" task on any dependency projects.

......................
:: problems summary ::
:::: WARNINGS
                module not found: org.gradle#api;1.0

I tryed something like:
task retrieveRuntimeLibs << {
  copy {
     from configurations.runtime.files {dep -> dep instanceof
ExternalDependency}
     into 'runtimeLibs'
  }
}

but didn't seem to make any difference.

thanks,
Philip


On Fri, Aug 21, 2009 at 3:31 AM, Hans Dockter<mail@...> wrote:

>
> On Jun 13, 2009, at 7:40 AM, Helmut Denk wrote:
>
>>
>> for the interested user ...
>> one way to do this is:
>>
>>
>> task retrieveRuntimeLibs << {
>>   Set files = configurations.runtime.resolve()
>>   ant {
>>       files.each {
>>           copy(file: it, todir: 'runtimeLibs')
>>       }
>>   }
>> }
>
> In trunk you can write:
>
> task retrieveRuntimeLibs << {
>   copy {
>      from configurations.runtime.files
>      into 'runtimeLibs'
>   }
> }
>
> With 0.7 you can also specify filters based on dependency properties:
>
> task retrieveRuntimeLibs << {
>   copy {
>      from configurations.runtime.files { dep -> dep.group = 'something' }
>      into 'runtimeLibs'
>   }
> }
>
> In trunk there is also the feature to copy artifacts to necessarily tp a
> name they have in the local repository, but based on the properties of the
> artifact object.
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project Manager
> http://www.gradle.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this list, please visit:
>
>   http://xircles.codehaus.org/manage_email
>
>
>

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

    http://xircles.codehaus.org/manage_email

[hdockter]

On Aug 24, 2009, at 6:29 PM, Philip Crotwell wrote:

> Hi
>
> Is there a way to distinguish between multiproject dependencies and
> remote jar dependencies? For example in
> gradle/src/samples/java/multiproject/services/webservice
> the dependencies look like:
>
> dependencies {
>    compile project(':shared'),
> 'commons-collections:commons-collections:3.2@jar',
> 'commons-io:commons-io:1.2', 'commons-lang:commons-lang:2.4@jar'
>    compile project(path: ':api', configuration: 'spi')
>    runtime project(':api')
> }
>
>
> then the below copy fails if the api subproject has not yet been
> built, which is not what you want if you are just trying to get all
> remote dependencies downloaded so you can work "offline". Ideally I
> suppose you would want to download all remote jar dependencies and
> then run the "retrieveRuntimeLibs" task on any dependency projects.
>
> ......................
> :: problems summary ::
> :::: WARNINGS
>                module not found: org.gradle#api;1.0
>
> I tryed something like:
> task retrieveRuntimeLibs << {
>  copy {
>     from configurations.runtime.files {dep -> dep instanceof
> ExternalDependency}
>     into 'runtimeLibs'
>  }
> }
>
> but didn't seem to make any difference.

Let's assume the api project would have a dependency on commons-
math-2.0 and commons-collection on commons-math-1.0. Let's further  
assume those are the only dependencies of the runtime configuration.

It is a feature that configurations.runtime.files {dep -> dep  
instanceof ExternalDependency} then would return: commons-collection  
and commons-math-2.0. To provide this feature we need to know about  
the module descriptor of the api project and all the other module  
descriptors. The way Gradle establishes access to all those module  
descriptors is by resolving all dependencies and then applying the  
filter. Which means the api project needs to be build an published to  
the internal Gradle repository of the build.

If you do:

gradle test
gradle retrieveRuntimeLibs

everything should work fine. Of course this is not the way you want to  
work. There is already an issue to make Gradle smarter here by not  
requiring the project to be build and still be able to access its  
dependency module descriptor. For now there are two possible  
workarounds:

task retrieveRuntimeLibs(dependsOn:  
configurations.runtime.buildDependencies) { ... }

Now the api project is build and published to the internal repository  
before the configuration is resolved. This is a viable option. In  
particular with Gradle 0.8, as we will have implemented all the  
optimizations that a build for a project that has already been build  
and uploaded will be very fast.

Another alternative is to say:

task retrieveRuntimeLibs << { ... configurations.runtime.copyRecursive  
{dep -> dep instanceof ExternalDependency}.files ... }

The possible problem with this approach it that it would return  
commons-collection and commons-math-1.0 for the example from above.

As said, in the future your code above should work out of the box.

- Hans

--
Hans Dockter
Gradle Project Manager
http://www.gradle.org








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

    http://xircles.codehaus.org/manage_email