Maven 3 seems to be coming soon since Maven 3.0-beta-1 was recently released. However, progress on Mercury (the new maven dependency resolver) seems to have stopped indefinitely [1]. So Maven will continue to use the current resolver for the near future at least until 3.1 or 4.0.
[1]http://svn.apache.org/viewvc?view=revision&revision=941373 Jason Porter wrote: > That makes a lot of sense Hans, well written. Now if Jason Van Zyl > and team could get Maven 3 and Mercury out the door :) > > On Tue, May 18, 2010 at 15:46, Hans Dockter <[email protected]> wrote: >> 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 >>> >>> >> > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
