In my current project, I am wrapping a complex project built with Ant. We have made some changes to that project’s sources so we need to build these modified sources, collect the artifacts and then add those artifacts to the classpath of some of our own modules.
My current approach is to “emulate” some of the Java plugin tasks such as ‘build’, ‘assemble’, ‘compileJava’ with custom tasks that call out to the ant build. However, this is not entirely satisfactory as it doesn’t, for example, honor any up-to-date checks.
At some point, we may port the dependent project’s build itself to Gradle which would presumably simplify things greatly, but for now, we haven’t done it.
Is there some intermediate step that might be a good middle ground?
The usual way to wrap an Ant build is to use ‘ant.importBuild’. You can then declare inputs and outputs for the wrapped tasks to get up-to-date checks. The user guide has more information on both topics.
Hm. I think I didn’t wind up doing this because I wanted to depend on the artifacts in another project in the multi-project build using a dependency like “compile project(”:wrapped") and it would try to trigger tasks with java convention.
Maybe I’ll play with it again and see if I can get it working. Thanks. Will keep you updated.
One immediate problem is that the ‘build.xml’ includes tasks like ‘test’ and ‘clean’ which conflict with applying any of the base plugins.
One of the other things I’d like is to have it possible to have Gradle generate the .classpath and .project files for Eclipse for this wrapped project (even if I have to duplicate dependency declaration and sourceSet declaration).
Typically you would import an Ant build into an “empty” Gradle project and just add tasks selectively for things that the Ant task doesn’t cover yet. There is an open feature request for prefixing Ant tasks so that no name collisions occur.
The “problem” is that I also want this to integrate nicely with Eclipse and the easiest way to do that is to apply plugin: “java”. I’ve gone in and re-named the tasks in the build.xml to work around this for now. (Actually, I applied only java-base and then I only had to rename test and clean; applying java would cause more things to conflict.) I had to do a lot of Gradle source code reading to figure out how to get various things working, but even your suggestions here have greatly improved things.