On Sun, May 16, 2010 at 18:59, Adam Murdoch <[email protected]> wrote: > > > On 14/05/10 1:04 AM, Jason Porter wrote: >> >> I was going through the Ivy archives and it looks like there's only >> one active committer now. It's a great project, but seems to be >> losing steam and people. They haven't cut a release since October >> 2009 but may be working on one now. Seven months between releases is >> a bit excessive IMO. >> >> In talking with Hans and also Jason Van Zyl it looks like Maven >> Mercury (this will eventually be the core of all things that are >> artifacts in maven and will be a stand alone lib) is at least three >> weeks out (probably more though). I'd love to see that used in Gradle >> so we're always compatible with poms (without having to manually >> specify each dep in a client module), but it's not publicly available >> to even start looking at integration :( >> >> The current Ivy 2.1.0 has problems with poms that are newer (Maven >> 2.0.9+) because of tags that Ivy does not recognize, so artifacts that >> are created with these newer poms do not resolve correctly. I >> currently only see two options for fixing this: >> >> 1. Upgrade to a SNAPSHOT of ivy trunk >> 2. Integrate maven 2 / maven 3 into gradle for artifact resolution >> (this is not a simple task from my exploration) >> >> I think the Ivy idea is a better route for the short term (possibly >> 0.9 release or 0.9 preview 2). >> >> Thoughts? >> > > I think what we should do, regardless of the state of ivy, is to decouple > Gradle's dsl and api from Ivy's, so that Gradle has the freedom to choose > whether to use ivy or Mercury or whatever under the covers as is > appropriate.
Sounds like a good idea in general. > The main place we are coupled to ivy is the repository api: We use ivy's > Resolver interface to represent a Gradle repository. We should replace this > with a Gradle-specific and ivy-independent Repository interface. You might > still be able to use an ivy resolver directly, but you might have to opt in > to ivy, by, say, applying an 'ivy' plugin. I'm not so sure I like this idea as much. Any build tool nowadays needs a way to resolve dependencies, it's become so common place now. The idea of having to opt-in to ivy or mercury seems like an extra step that really shouldn't be needed, or at the very least one that we shouldn't be putting on the shoulders of the users. Unless I'm missing something it seems like it's either Ivy or Mercury (some day) by default. I'd hate for us to reinvent parsing metadata from a repo. It's been done at least three times that I know of (Ivy, Builder, Maven). ATM, I don't have a good answer (maybe the answer is to dump Ivy and use Mercury when it's out), but abstracting the interface I think is a good idea. > There are a few other places where ivy concepts leak into the Gradle dsl and > api, which we should clean up, so that they're available only when you use > the 'ivy' plugin. I'm pretty sure this will be a 1.0 (0.10 ?) thing. 0.9 is pretty booked, and we really need to cut a final release soon anyway. > > -- > > Adam Murdoch > Gradle Developer > http://www.gradle.org > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- Jason Porter Software Engineer Open Source Advocate PGP key id: 926CCFF5 PGP key available at: keyserver.net, pgp.mit.edu --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
