On Mon, May 24, 2010 at 22:20, Paul Gier <[email protected]> wrote: > 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
In a conversation I had with Jason Van Zyl on IRC (I have the log floating around if you'd like to see it) he said Mercury was being pushed off until 3.1, and has been moved to a github repo, the apache svn repo is dead. > 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 > > > -- 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
