buildr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <alex.boisv...@gmail.com>
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 <
pepijn.vaneeckhoudt@luciad.com> 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
hack.

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.

alex

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