Hi Michael, On Dec 28, 2011, at 1:43 PM, Michael Guymon wrote:
> > So I have slowly being making progress on a dependency manager for buildr and > have put together a very simple implementation based on Bundler using Aether > for the transitive resolution. I would love some feed back on what I have > pieced together so far. > > https://github.com/mguymon/lockjar > > A Jarfile is used to specify the repos and dependencies, an example: > > repository 'http://repository.jboss.org/nexus/content/groups/public-jboss' > jar "com.slackworks:model-citizen:0.1" > jar "org.apache.mina:mina-core:2.0.4" do exclude "com.package", > "com.another.package:blah:7" end > > Would produce a Jarfile.lock with absolute paths to the local jars, an > example: > > --- > > 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. Rhett > > Next step is moving the project towards something that integrates nicely with > Buildr. Maybe allow the Jarfile to be defined directly in the buildfile? > > thanks, > Michael > > On 11/04/2011 06:13 AM, Peter Tillotson wrote: >> This sounds pretty good - some thoughts inline below >> >>> Dependency Resolution >>> >>> * Dependency resolution is optional >>> * Resolve Transitive Dependencies for an artifact(s) >>> * Create/Rebuild a dependency file >>> * Lock dependencies based on the dependency file >> >> Transitive resolution should be capable of producing the same dependencies >> as maven ( possibly via an interface compatible plugin ) and support the >> full maven spec. >> >> I'd add filtering and blacklist has been useful as well. I always have to >> package(:war).libs.reject! { |lib| lib.group == 'servlet-api' } this is a >> reasonable compile dependency that shouldn't get into runtime. If the >> dependencies file something like the following >> >> runtime: >> - org.apache.cassandra:cassalndra-all:1.0.1 >> exclude: >> - *:servlet-api:* >> - *:junit:* >> >> That would be pretty handy - I really like the idea of the dependency report >> effectively acting as the whitelist / blacklist so when the universe changes >> my build file doesn't necessarily have to :-) >> >>> Maven interop >>> >>> * Generate a maven POM based on a Buildr project >>> * Create& deploy maven friendly artifacts based on a Buildr project >>> >>> Would there be any benefit for having Ivy interoperability as well? >> >> p >> >> ________________________________ >> From: Michael Guymon<michael.guy...@gmail.com> >> To: dev@buildr.apache.org >> Sent: Thursday, 3 November 2011, 23:16 >> Subject: Re: Experiences with transitive dependencies in buildr >> >> >> So based on the discussion, it sounds like the following solutions would >> work well: >> >> Dependency Resolution >> >> * Dependency resolution is optional >> * Resolve Transitive Dependencies for an artifact(s) >> * Create/Rebuild a dependency file >> * Lock dependencies based on the dependency file >> >> Maven interop >> >> * Generate a maven POM based on a Buildr project >> * Create& deploy maven friendly artifacts based on a Buildr project >> >> Would there be any benefit for having Ivy interoperability as well? >> >> On 11/02/2011 09:59 PM, Peter Donald wrote: >>> Hi, >>> >>> On Thu, Nov 3, 2011 at 12:26 AM, Chiaming Hsu<camy...@yahoo.com> wrote: >>>> If this becomes part of the core of buildr as Peter suggested, would there >>>> be performance impact when not using transitive dependencies? >>> I would hope not. >>> >>> I am not a huge fan of transitive closure across the builds when you >>> can't lock it down to a specific set (like Gemfile.lock or what Ivy4r >>> supports it seems). I don't object so much to the network chattiness >>> but due to the un-reproducible of builds. >>> >>> Aether would mainly used as the API for interacting with Maven repos >>> and for implementing transitive dependencies of maven artifacts. >>> >>> >
