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.
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.
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.
-- Adam Murdoch Gradle Developer http://www.gradle.org --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
