Hi, devs! I'd like to introduce you the *Gradle maven-embedder plugin*. The target is the same as with my maven2gradle converter<http://blog.sadogursky.com/2010/02/23/maven2-to-gradle-convertor/>, but the implementation is much more awesome :) The plugin embeds Maven in it and gets all the information needed for the build from maven after it parsed the pom.xml The source code is on github<http://github.com/jbaruch/Gradle-Maven-embedder-Plugin>, the plugin is deployed to Artifactory <http://repo.jfrog.org/artifactory/webapp/browserepo.html?pathId=gradle-release-local%3Aorg%2Fgradle%2Fplugins%2Fgradle-mavenembedder-plugin>and you can try it according to the readme<http://github.com/jbaruch/Gradle-Maven-embedder-Plugin/blob/master/README> .
Now, except of the PR, the reason I write this to you is that I have number of unsolved problems, and your advice will be greatly appreciated: 1. Gradle contains maven-ant-tasks-2.1.0.jar in its lib directory with conflicts with maven3 jars I need for my plugin. maven-ant-tasks can not be ported to work with maven3 easily, since JVZ changed plexus container APIs dramatically somewhere between versions alpha-25 and alpha-37 :) Generally, maven-ant-tasks is obsolete way to run maven for gradle-maven-plugin, and that plugin should probably be ported to Aether<http://www.sonatype.com/people/2010/08/introducing-aether/>. Other option is isolate plugins classpathes, although looking at Maven's source with classworlds, I think rewriting gradle-maven-plugin will be easier :) 2. Packagings. Today I only support "jar" and "war" packagings by enabling java and war plugins accordingly. Any other Maven packagings<http://www.sonatype.com/books/mvnref-book/reference/lifecycle-sect-package-specific.html>that I should support? Maybe "ear"? I could add the package task for it... Dunno... 3. The plugin is capable of executing Maven plugins. As PoC I run maven-clean-plugin after Gradle's clean task. Two questions in that regard: 1. I am not sure running all maven plugins from the pom.xml makes sense, the corresponding Gradle plugin (e.g. java) runs pretty much the same tasks - compile, test, package, etc. On the other side, the user might add specific configuration to all those plugins, and expect special behavior from them (e.g. adding additional directories to delete in maven-clean-plugin, I covered this one). I will be happy to hear your opinion on that matter - which Maven plugins should I run? 2. If I want to run custom plugins (and I see it as a main benefit of my plugin) I need them to be in the classpath and I need which ones to run. For the earlier there are two ways to achieve it - 1) make the user add them to buildscript classpath or 2) execute Maven's lookups in repositories. As much as I don't like the first option, I like the second one less. What do you say? For the later - how can I know which plugins should I run? Should I maintain a list of default plugins and run all the plugins which aren't there? 4. Another obstacle I have is in-project dependencies. Inside my code I can distinguish between external dependencies and inter-module dependencies, but I am not sure how can I generate correct gradle in-project dependency. Here's the problem: I have in hand groupId:artifactId:version string of maven dependency which relates to another module in the build. On the other hand, the only thing I know about Gradle modules are names from settings.xml. Will it be good enough to match artifactId with module name and ignore all the rest? Will it be durable enough? That's about it, thanks for taking a look. -- Best Regards, Baruch
