buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Guymon <>
Subject Re: Experiences with transitive dependencies in buildr
Date Wed, 28 Dec 2011 20:13:29 GMT
Hi Rehett,

On 12/28/2011 03:02 PM, Rhett Sutphin wrote:
>> ---
>> >  
>> >  dependencies:
>> >    com.slackworks:model-citizen:0.1: /home/zinger/devel/projects/swx/lockjar/tmp/test-repo/com/slackworks/model-citizen/0.1/model-citizen-0.1.jar
>> >    org.apache.mina:mina-core:jar:2.0.4: /home/zinger/devel/projects/swx/lockjar/tmp/test-repo/org/apache/mina/mina-core/2.0.4/mina-core-2.0.4.jar
>> >    org.slf4j:slf4j-api:jar:1.6.1: /home/zinger/devel/projects/swx/lockjar/tmp/test-repo/org/slf4j/slf4j-api/1.6.1/slf4j-api-1.6.1.jar
>> >  
>> >  repositories:
>> >    -
>> >  
>> >  
>> >  The Jarfile.lock is standard yaml, not sure if a custom dsl is needed. Similar
to bundler, the Jarfile.lock has to be generated before getting access to the dependencies.
Once the Jarfile.lock is generated, Buildr can reuse it instead of checking for transitive
dependencies every time.
> This is a very interesting idea. Might I suggest, though, that you have the lockfile
contain just the list of dependent artifacts? That way you could check it in and use it to
ensure that all developers/CI/etc. are using the same artifact versions. Converting from a
buildr artifact name to the local path is not an expensive operation.
That makes sense. I wanted to support jars that are not hosted in a 
maven repository and have to be stored with a project. This could be 
handled similar to the above example, artifact name followed by a 
relative path. Otherwise it would just be the artifact name.

View raw message