buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Young <>
Subject Re: Integrating with JPackage
Date Mon, 19 Apr 2010 19:35:41 GMT
On 04/19/2010 01:31 PM, Antoine Toulme wrote:
> A couple of quick comments while reading your gist:

Thanks for the feed back.  THis is "proof-of-concept" code, that will 
make it possible to build, but certainly not ready for prime time.

> You should avoid at all costs using global variables with $. In practice, it
> is best to use a singleton approach.

There is a difference between a global variable and a a singleton.  In 
this case, the difference is academic, but In general is is poor design 
to use a Class name as the way to locate an instance variable.

In this case, it would more likely make sense for there to be some 
variable at the module scope, but I have to admit that my ruby is fresh 
enough that I don't know how to do this off the top of my head, or if 
Ruby even allows such a thing.  A better solution would be to make the 
repository itself an object and the parsing to be part of the 
construction of the repo object.  Or something.

> Use info, warn, error to log stuff.
Yeah.  Still developing this.  puts is  this poor man's  debugger.

> If you need to check that an object is nil, you can do object.nil?
Thanks.  That is a new rubiysm for me.  I like the ability to avoid 
accidental assignment.
> Last but actually the most important item, we need specs to integrate those
> changes. For the first gist, a couple of specs demonstrating that you can
> monkey patch successfully the Repositories instance would be great. For the
> module itself, it'd be great for you to have specs to deal with the absence
> of the xml file, malformed file, etc.
specs?  That word means a few different things to me, but I suspect it 
means something specific here.  Can you send me a pointer?

> I think we would be interested into this extension to be part of Buidr
> itself. I would recommend that people interested by this functionality do an
> extra require in their Buildfile: require "buildr/jpp" for example, much
> like you do an extra require to add ecj as a compiler today.
I'm almost tempted to say that it should be a switch to buildr itself as 
opposed to a change to the buildfile.  Chosing which repository scheme 
to use is a distribution decsion, one that may not be mirrored by the 
people writing the code that gets distributed.  WHile in Candlepin we do 
have the ability to dictate which version of buildr to use for our 
purposes, we have the goal that one should not need JPackage to build, 
or even that the end use is building on Fedora or even Linux.

mvn-jpp is run a a wrapper that just call mvn with a couple of switches:

-Dmaven2.offline.mode -Dmaven2.ignore.versions -Dmaven2.usejppjars

I'm tempted to say that buildr should implement at least the last two as 

In building the hash for jar to version, I'm currently adding two keys 
for each package:  One with the version info and one without.  Ideally, 
we'd allow multiple versions in JPP, and not have to use 

So perhaps we could allow a switch which is buildr --usejpp

> Thanks for your interest in Buildr!
> Antoine
> On Mon, Apr 19, 2010 at 10:23, Adam Young<>  wrote:
>> We have been happily using builder for For the Candlepin project fora few
>> months now.  As we get closer to "productization" I've been looking into a
>> way to build the project from sources, to include all of the dependencies.
>>   Dependencies downloaded from the Maven repositories are often based at some
>> point on checked-in binaries.  An alternative approach, and the which is
>> embraced by JPackage, is to:
>> A) Create Source level RPMS for all dependencies and
>> B)  Create local maven repo out of those jars.
>> This is the approach I've been pursuing, and so far, so good.  In order to
>> take advantage of this approach, I've had to modify my version of builder as
>> well as call builder with an additional module. The change to buildr proper
>> allows the local module to overload how the repository path is built:
>> This creates a module level function named build_path with the existing
>> logic.
>> My overloaded version goes into a local script I am createivle calling
>> ./localbuild.rb.
>> Here's a first draft.
>> Note that this version redefines build_path.
>> I used libxml to parse the maven repository mapping file, because xmlsimple
>> was flaking out on me.  I'm sure I could have debugged it further, but
>> instead I went with what seems to be a faster and simpler approach using
>> streaming.
>> This page explains the Maven version of JPP, and the rules  buildr needs to
>> follow to make use of the JPP approach.
>> Is there other interest in this approach?

View raw message