Migration Plugin


(sirinath1978m) #1

Is it possible to add features to the migration plugin to use sub projects which might use other build management systems which you do not have the control to migrate them to work smoothly with Gradle.

Wrestling with build management issues is time wasted as this can be used in coding and real bug fixing. Adaptation of Graddle will be hampered as trying to champion the use of Graddle will create more issues than the ease of use it provides when there are other sub parts which use other build management like STB. Also it is worth while to consider Buildr also as it is JVM based.

Also another issue to tackle is if Graddle is the sub project and other parent branches are on another build management system. In case of Maven an auto generation of a POM file might be helpful. But don’t limit this just to Maven support.


(Peter Niederwieser) #2

Our current plan is to support migrations from older Gradle versions, Maven, and Ant.


(sirinath1978m) #3

Pl. at least include SBT. Buildr is also nice to have as it is a JVM based build management system.


(sirinath1978m) #4

SBT is a necessity as many Scala projects use it and I do not think it is difficult to integrate. Even buildr. This would save a lot of nightmares when sub projects are in other systems.

With regard to Maven make sure the Maven plugin are activated correctly. Also for the other systems like SBT are supported also.


(sirinath1978m) #5

The key is 1) Any sub projects which are maintained in other than Gradle should be easily usable as a Gradle project even if it has plugins 2) Any parent project on another build system should be able use gradle. It should generate a plugin stub such that any gradle related plugins can be ivoked. E.g. if the parent project is a Maven project we should be able to get a POM generated with relevant maven Gradle plugin which ensures the relevant side effects of Gradle build are maintained. 3) The other possibility is the Gradle sub project is in the middle of two project with a parent and sub project on other build systems.


(Peter Niederwieser) #6

Again, we don’t currently have any plans/budget for that, but I encourage you to contribute once a first version of the plugin is out.


(Hans Dockter) #7

To avoid any confusion. The term ‘migration plugin’ is already internally used for an upcoming plugin that helps with build migrations in a different sense. This upcoming plugin will check whether two builds produces the same output when they are run with different versions of Gradle or with Maven vs. Gradle or with Ant vs. Gradle.

What you are proposing is what we would call an import functionality. I agree that this is something very important and would make life much easier for our users. If you look at our roadmap you can see that such a deep Maven import is a high priority item on our list. With Ant we provide such an import already.

What you can always easily do is to use the Exec or JavaExec task to wrap an external build system.


(sirinath1978m) #8

There is more sense of reliability if this functionality is provided from Gradle it self than the end users. Besides in my case, I am familiar with Maven and Gradle only. So might do a poor job at integrating this. Besides time spent wrestling build management system issues is developer time wasted. This should be a time saver and should not cause additional pain for choosing Gradle in term of development and carrier.

It is definitely the case when you do not have control over the sub projects so some deep import functionality is needed. Many Scala programmers now by default use SBT. This is something Gradle cannot ignore. And to much lesser extent the presence of Builr.


(sirinath1978m) #9

This should be both import and export. Export is needed if Gradle is used in a sub project and parent is on something else.