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 >> >> > > -- 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
