On 7/08/10 8:09 PM, Baruch Sadogursky wrote:
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 :)
It certainly is. This is fantastic.
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 :)
The maven plugin will get reworked quite a bit after 0.9 is out, so I
think we could update it to use maven 3 at the same time.
1. 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...
It feels like the plugin should really just configure stuff, rather than
implement extra behaviour itself. So, I would only support those
packagings for which there's a Gradle equivalent. If we want to support
'ear' packaging, then we should add an 'ear' plugin and have the
embedder plugin simply configure it.
1. 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?
When it comes to running plugins, I guess there's a few questions that
we need to answer for a given build:
- where should the meta-data for the project come from? Does it come
from the pom or from the build script?
- who should build the standard stuff? Do the Gradle plugins build the
artifacts? Or does Maven?
- which additional Maven plugins should get executed? The ones listed in
the pom? Or additional ones defined in the build script?
I guess there's a few use cases:
- Migrating from Maven. Probably want to use the meta-data from the pom,
use Gradle plugins for building, maybe run additional plugins listed in
the pom
- Build aggregation. Probably want Maven to do everything.
- Using custom Maven plugins. Probably want to use the meta-data from
the build script, and run the Maven plugins defined in the build script.
1. 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?
Without knowing the effort involved, I'd say you want to be able to
define plugins in the build script and/or pom, but I think Maven should
do the work of handling the lookups and classpaths. The less behaviour
we have to emulate the better.
1. 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?
1. 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?
Not really. Better to match on Project (group, name, version). But even
this isn't reliable, because one can change archivesBaseName or the
(groupId, artifactId, version) on the generated pom(s). However, there's
no good way to get at this for now. Part of the dependency DSL working
after the 0.9 release will make it easy to map from a (group,
artifactId, version) to a Project instance.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
CTO, Gradle Inc. - Gradle Training, Support, Consulting
http://www.gradle.biz
