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.guy...@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.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.
