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
