Hi Klaus, My approach to this was to automate the extraction of the pom dependencies into the build.gradle and pay the cost of maintaining the duplicated dependencies. Nothing pretty.
The best point to infect is the biggest pain point. In my case it was grouping interrelated projects into a single multi-project build, making version management and creating a single release artifact a non-issue. Hope that helps, Merlyn On Mon, 2011-05-23 at 04:48 -0700, klausb wrote: > In order to prove a smooth Gradle migration inside a larger maven build, I > look for ways to use Gradle without forcing to much build-refactoring. My > idea is to migrate a small subproject from maven to Gradle, by keeping the > inherited dependencies. I searched already, but without success. > > What is the best approach to 'infect' a maven build setup with the Gradle > virus, without touching too many pom files. Ideally I would just change the > local pom and redirect the build to Gradle, including dependencies coming > from parent poms. > > - klaus. > > -- > View this message in context: > http://gradle.1045684.n5.nabble.com/Calling-a-Gradle-project-in-context-of-a-larger-maven-build-tp4418806p4418806.html > Sent from the gradle-user mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
