buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <>
Subject Re: Improved Maven repository handling
Date Wed, 24 Feb 2010 18:08:52 GMT
On Wed, Feb 24, 2010 at 9:03 AM, Pepijn Van Eeckhoudt <> wrote:

> On 24/2/2010 06:28, Alex Boisvert wrote:
>> There's no work underway for this at the moment so the path is clear :)
>> I personally would try to go with the Maven ant tasks since it's less code
>> to maintain but that would probably depend on how much glue and duct tape
>> is
>> necessary for the integration.  Otherwise, a Ruby implementation would
>> probably fit in<  100 lines**  given that we already have building blocks
>> for repository, artifact, upload/download, etc.
> Well, here's what I tinkered together last week. The intention is that
> artifact coordinates and dependencies are defined in an external pom.xml
> file. This is then read to resolve dependencies and when
> deploying/installing artifacts.
> I got the basics to work the way I wanted them to, but I bumped into a
> major annoyance relating to the super-pom concept. The super pom defines the
> maven central repository and it seems the only way to completely disable it
> is to redeclare it in each project pom file, disabling it for releases and
> snapshots. It seemed to me that this should be feasible from the
> settings.xml but no matter what I tried the maven ant tasks kept trying to
> contact repo1. For my use case, this is a showstopper so I kind of gave up
> on using the maven ant tasks.

Ugh, yeah, that doesn't seem to be workable unless we can automatically
"patch" the poms to do the right thing and even then it seems like a bad

I revisited the ivy4r extension and played with that a bit instead but I've
> run into a bit of an issue relating to how buildr retrieves its own
> dependencies. I basically would like to use ivy (or the maven ant tasks for
> that matter) for all artifact downloads. This of course requires the ant
> jars themselves and the respective ant task jars. What I haven't been able
> to solve is how I can get buildr to bootstrap itself given this setup. I.e.,
> how can I use ivy to download ant if neither ant nor ivy are downloaded yet.
> In the attached maven extension I ended up using the default buildr behavior
> for ant and the maven ant tasks and maven for everything else. I would like
> to find a better solution for this though. My end goal is to define the
> repository information only in the ivy/maven metadata files and not have to
> duplicate this in the buildfile. Any suggestions on how to tackle this?
> Ivy4r works around this by packaging it's dependencies in a gem. Is that the
> best way to go?

No easy answer here;  you could parse the Ivy/Maven metadata to retrieve the
information needed to bootstrap, or assume Ivy/Ant are already installed, or
do like Ivy4r as you suggested.

I like the last one the least since the dependencies are static but that may
not be as bad as it sounds.


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