buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Guymon <michael.guy...@gmail.com>
Subject Re: Experiences with transitive dependencies in buildr
Date Fri, 30 Dec 2011 00:00:20 GMT

Yeah, did not even think of that. That makes a good argument for using a 
dsl with the lock file, something along the lines of:

compile do
     jar 'org.apache:tomcat:0.1'
end

test do
     jar 'junit:junit:1.0'
end

The addition thing I pondered a little was scoping for projects. Have 
global scopes  that all projects inherit and individual scopes for each 
project:

# global compile
compile do
     jar 'org.apache:tomcat:0.1'
end

# global test
test do
     jar 'junit:junit:1.0'
end

# a_project_name only dependencies
project( :a_project_name ) do

     # a_project_name's compile
     compile do
         jar 'org.apache:solr:0.1'
     end
end


On 12/29/2011 04:42 PM, Alex Boisvert wrote:
> Neat!
>
> I think something missing (unless I missed it) is the notion of
> scopes/groups for artifacts.
>
> With respect to Buildr integration, it would be nice if it could reuse the
> repositories specified in the buildfile (e.g. Buildr.repositories.remote)
> and maybe allow mapping of groups to Buildr's built-in
> compile/test/package/run/... tasks, similar to how ivy4r does it, e.g.,
>
>    ivy.conf(
>      :compile =>  ['buildtime', 'default', 'hadoop'],
>      :test =>  ['buildtime', 'default', 'test'],
>      :package =>  'default'
>    )
>
> (there are alternate syntaxes for this, I'm just copying&  pasting the
> closest example I had).
>
> alex
>
> On Wed, Dec 28, 2011 at 11:43 AM, Michael Guymon
> <michael.guymon@gmail.com>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<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<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<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.
>>
>> 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.guymon@gmail.**com<michael.guymon@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<camyhsu@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.
>>>>
>>>>
>>>>


Mime
View raw message