This all makes a lot of sense to me. Hans
On Wed, Jun 6, 2012 at 5:52 AM, Adam Murdoch <[email protected]>wrote: > > On 06/06/2012, at 4:37 AM, Daz DeBoer wrote: > > G'day > > Currently we use maven2 internally, both for generation of POM files for > publishing, and via the maven ant tasks for doing the actual publishing. We > don't use maven code at all for dependency resolution, we use a copy of > ivy's reverse engineered pom parsing code. > > There would be a number of benefits of an upgrade to maven3: > > - The maven import stuff that we want to assimilate uses maven3; we'd > need a compatible version in order to bring it on board > - The Redhat guys want to get hibernate into fedora, which means > getting gradle into fedora. But only maven3 is available in Fedora, not > maven2. > - Using Maven3 for publishing effectively means using Aether. Aether > is a lot more pluggable than maven2, and we could potentially reuse our > transport goodness for publishing which still letting Maven+Aether do the > maven-specific stuff (pom.xml, maven-metadata.xml, ...). > - Maven3 is easier for us to embed in general: it would be possible to > replace our custom pom parsing code with calls to Maven3. This should help > us to handle parent poms, profiles, maven settings, dependency-management > etc, in a way which is consistent with how Maven does it. > - I did spike this, and it won't be too hard to get rid of our > custom parsing code. > > I've spiked the upgrade and it's certainly non-trivial. > > - Currently our test coverage for maven publication is not very good, > and we'd need to add a lot of integration tests to ensure a smooth upgrade. > (In some ways this is like our dependency on ivy used to be: we assume that > maven publication 'just works', and don't test it thoroughly). > - The entire publishing side of things would need to be rewritten to > use Aether instead of the Maven-ant-tasks. This would mean updates to the > mavenDeployer used for uploadArchives, as well as the new PublicationPlugin > that was started > - The pom generation stuff seems pretty compatible from > maven2->maven3, but again our test coverage isn't good. > - We'd need to verify that the PomBuilder stuff taken from polyglot > maven still works (I didn't test this). > > > Some other things: > * We'd also need to update the maven settings.xml handling, used for > things like repositories.mavenLocal() and ~/.m2 reuse. > * We'd need to handle MavenDeployer.addProtocolProviderJars() and > BaseMavenDeployer.configuration. > > > > So overall this would be a fairly major undertaking. Doing it in a 100% > backward compatible way would be very difficult, in particular because the > mavenDeployer exposes a couple of underlying maven/ant classes which are > tied to maven2. This would probably only affect a few users, but removing > maven2 would be a breaking change. > > > Removing the maven 2 classes is pretty much not an option before 2.0, > because both they and the maven wagon jars are exposed through the API. > Here's what I think we should do instead: > > 1. Put together a bunch of integration test coverage for maven > publication, pom customisation and using the wagon jars. > 2. Rename the maven 3 model and settings classes using jarjar, and include > these renamed classes in the distro alongside all the maven 2 stuff. > 3. Change the settings.xml handling to use maven 3 classes, so that the > fedora port can continue. > 4. Add the maven pom converter stuff, changing it to use the renamed maven > 3 classes. > > Over time, we want to replace the existing maven publishing DSL with > something new, that does not expose any non-Gradle classes. Using our > replace/deprecate/remove approach to new DSLs, we can eventually remove > MavenDeployer and related stuff, along with the maven 2 classes, and move > back to the maven 3 classes with their original names. > > I'm very keen for all publishing DSLs - ivy, old maven, new maven, > whatever - to use the same infrastructure under the covers. In the long > term, the only thing we should be using native ivy or maven classes for is > metadata parsing and generation, and nothing else - no transport, no > authentication, no caching, no progress logging, no model customisation, > nothing. > > So, that means that in parallel to the replace/deprecate/remove for > replacing the old maven publishing DSL with something new, we might also > look at incrementally porting the old maven DSL to use aether for > publishing, combined with maven 2 for the pom > generation/customisation. Publishing would then look something like this: > > * If using the old maven DSL, and wagon jars are specified, we use the > aether -> wagon adapter with the given jars. Use maven 2 to generate the > pom. > * If using the old maven DSL, and no wagon jars are specified, we use > aether connector implementations that are backed by our transports. Use > maven 2 to generate the pom. > * If using the new DSL to publish to a maven repository, we use aether > connectors backed by our transports. Use maven 2 to generate the pom. > * If using the old DSL, and an Ivy DependencyResolver implementation has > been provided, delegate to the resolver. > * If using the old DSL, and an ArtifactRepository implementation has been > provided, use our transports. Use ivy to generate the ivy.xml. > * If using the new DSL to publish to an ivy repository, we use our > transports. Use ivy to generate the ivy.xml. > > Using maven 2/3 classes to take care of pom.xml and metadata.xml parsing > during resolution could happen in parallel to the changes in publication, > driven by bug fixes. > > > -- > Adam Murdoch > Gradle Co-founder > http://www.gradle.org > VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting > http://www.gradleware.com > >
