On 17/05/10 2:37 PM, Jason Porter wrote:
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.
I meant opting into using the ivy api in your build script, such as
providing an ivy Resolver implementation as you can do now, or to use
some ivy specific feature that we don't want to model in the core Gradle
api.
I would think that the core will be able to use both ivy and maven
repositories, but you'd declare them in some type independent way. Under
the covers, we would use ivy or mercury, or even some combination, to
wire everything together.
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.
We certainly don't want to do that. We would use ivy to do the parsing
for an ivy.xml, and mercury to do the parsing for a pom.xml. Ditto for
ivy.xml and pom.xml generation. We would probably also use bits of
either ivy or mercury to do the actual resolving and publishing.
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.
Definitely.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
