Hi Jason, I see your point with Ivy.
There are a couple of objectives we want to meet: - 100 percent compatibility with Ivy for resolving/publishing to an Ivy repository (We provide this already) - 100 percent compatibility with Maven 3 for resolving/publishing to a Maven repository. (We almost provide this. As you pointed out there are some issues when reading for certain poms. But they will be fixed when switching to an Ivy/Mercury combo) - Gradle wants to be strategy agnostic. Whether Ivy, Maven, a dir on the file system or a custom metatdata format. In Gradle all approaches should be able to be first class citizen in a build. (We support this to some degree. Custom metadata formats would be pretty hard to acoomodate at the moment). - Gradle's domain layer for describing your metadata wants to provide its very own abstractions completely independent of any other metadata format. It needs to be rich enough to easily map to Ivy/Maven for reading and publishing. We have gone some way on this route but there is more to do. For example to provide our own repository abstractions instead of using native Ivy classes (even if the Ivy classes are often hidden right now behind convenience methods like mavenCentral()). In general I think our current dependency handling is OK. But there is a lot of flexibility we will be able to provide by adding more of the right abstractions. It should be easy for example to use source archives as dependencies. They would get build as part of the resolution. For most of the stuff only the Gradle domain model should be important to our users. What technologies we use under the hood is an implementation details. This is our safest bet for the future. And stuff is tailored to be used via our DSL. Only if you want to do metadata specific customizations you can apply the Maven/Ivy plugin (the latter does not exists yet). In this case Gradle will provide the native domain objects of the respective technology which you then will be able to manipulate. - Hans -- Hans Dockter Founder, Gradle http://www.gradle.org, http://twitter.com/gradleorg CEO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz On Thu, May 13, 2010 at 5:04 PM, Jason Porter <[email protected]>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? > > -- > 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 > > >
