If you set up a flatDir resolver it will never copy the artifacts into the
cache, and hence you'll always get the "latest" version using version numbers
or even just the static -SNAPSHOT classifier.
If you really need to have timestamps as part of the filename, then it should
be possible to simply treat them as part of the revision number.
apply plugin: 'java'
defaultTasks 'build'
repoPath = '/abs/path/to/lib/'
repositories {
// NOTE: Pin repository path to project since it will always exist,
// but change patterns
flatDir name: 'localRepository', dirs: path
localRepository {
def patterns = [repoPath + '[module](-[revision])(-[classifier]).[ext]']
setArtifactPatterns(patterns)
}
}
dependencies
{
compile ':slf4j-api:1.6.1+:SNAPSHOT'
}
If you have say slf4j-api-1.6.1.jar, and
slf4j-api-1.6.1-20110616.101010-SNAPSHOT.jar and
slf4j-api-1.6.1-20110616.111111-SNAPSHOT.jar this will pick up the 111111
version.
You could also use ':slf4j-api:1.6.1-+:SNAPSHOT' for the same behavior.
Simply using the timestamp will also work if no version number is in place, so
':slf4j-api:+:SNAPSHOT' will always grab the latest snapshot, as long as the
timestamp is in a YYYYMMDD.HHMMSS format.
Fortunately for a local file resolver, using "+" and other range matches isn't
much of a performance penalty.
-Spencer
--- On Wed, 6/15/11, Mike Mills <[email protected]> wrote:
From: Mike Mills <[email protected]>
Subject: Re: [gradle-user] intra project build dependencies
To: [email protected]
Date: Wednesday, June 15, 2011, 9:26 PM
Thanks Eric, I forgot to mention that I had considered maven snapshots, but I
think it is clunky, especially as you have to define a pom.
It would he nice if there was a native gradle way of doing snapshots with Ivy,
but an earlier request to this list about that came up with no suggestions :(
I have been trying to define a flat dir for use as a local ivy repository, but
I can not find a way to set a resolver strategy that uses timestamps rather
than version number.
Any suggestions on how to configure a resolver strategy for a flatDir?
On 16 Jun 2011 10:11, "Eric Berry" <[email protected]> wrote:
> Oops, hit send too soon. Forgot you have to add your mavenLocal as a
> repository in project2.
> [code]
> repositories {
> mavenLocal()
> }
> [/code]
>
> On Wed, Jun 15, 2011 at 5:09 PM, Eric Berry <[email protected]> wrote:
>
>> One solution would be to use the maven plugin and SNAPSHOT versions.
>>
>> With the maven plugin you would run 'gradle install' in project1. That
>> would install the artifact in your ~/.m2/repository directory.
>>
>> Then you define the dependency in project2 as is.
>>
>>
>> On Wed, Jun 15, 2011 at 4:54 PM, Mike Mills <[email protected]> wrote:
>>
>>> I am having trouble converting two separate ant projects to gradle.
>>> The output of the first project is a dependency on the second project.
>>>
>>> Both projects are separate SVN checkouts, both projects will be
>>> changed frequently during development and there is currently two
>>> separate CI builds, one for each of the projects.
>>>
>>> So in the past I have checkout project1, then built it. Then checkout
>>> project2 and then built that including the artifact from project1 on
>>> the classpath.
>>>
>>> I am looking for the current way that these two projects can be linked
>>> with gradle.
>>>
>>> My first thought was to simply declare the following dependency in
>>> project2's build.gradle:
>>>
>>> dependencies {
>>> compile group: "project1", name: "core", version: "1.0.0"
>>> }
>>>
>>> The issue here is that once the core-1.0.0.jar file is resolved by
>>> gradle and is added to the local gradle cache, no more uploaded
>>> artifacts from project1 are picked up in project2
>>>
>>>
>>> My second thought was to create a "parent" build.gradle file where I
>>> could wire the projects together, but this file would not be checked
>>> into subversion and would make the CI build hard to implement.
>>>
>>>
>>> How do people on this list cope with this situation?
>>>
>>> Kind regards,
>>>
>>> -Mike
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe from this list, please visit:
>>>
>>> http://xircles.codehaus.org/manage_email
>>>
>>>
>>>
>>
>>
>> --
>> Learn from the past. Live in the present. Plan for the future.
>> Blog: http://eric-berry.blogspot.com
>> jEdit <http://www.jedit.org> - Programmer's Text Editor
>> Bazaar <http://bazaar.canonical.com> - Version Control for Humans
>>
>
>
>
> --
> Learn from the past. Live in the present. Plan for the future.
> Blog: http://eric-berry.blogspot.com
> jEdit <http://www.jedit.org> - Programmer's Text Editor
> Bazaar <http://bazaar.canonical.com> - Version Control for Humans
