buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Toulme <>
Subject Re: Integrating with JPackage
Date Mon, 19 Apr 2010 17:31:43 GMT
A couple of quick comments while reading your gist:
You should avoid at all costs using global variables with $. In practice, it
is best to use a singleton approach.

Use info, warn, error to log stuff.
If you need to check that an object is nil, you can do object.nil?

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.

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.

Thanks for your interest in Buildr!


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?

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message