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:
> -http://repository.jboss.org/nexus/content/groups/public-jboss
>
>
> 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.
