Thursday, March 6, 2014

Transition to Gradle

So after some researching, I think I found a reasonable way to transition to gradle android application builds. The general idea was to have as many things decoupled as possible so that I have some nice flexibility in my developer workflows without some major crippling break downs.

One, right now the android gradle build is still alpha and will continue to be that way until 1.0 and that should be reached sometime before Google IO 2014. On to of that we do not have full gradle support in the Eclipse ADT plugin including no support for AAR artifacts(Yeah they would happen to pick the AXIS 2 AAR archive extension name..way to go Google team for your research!).

Thus, right now if we do a project layout that supports gradle while supporting the need to have the test project nested in the app project than we can have the same project layouts for both ant and gradle with minimum fuss.If we also switch to using Google's Espresso Testing Kit than we get rid of the need ot run jython/python for testing or say JVM-Cucumber and thus have a cleaner less complex set of build scripts.

And by implementing findbugs and Jacoco report use in the ant builds we get full re-use of all the xsl/xml reporting stuff and the code QA metrics will be the same.

As far as dependency management IVY is being used as a temporary fudge until we move to gradle builds as Gradle has depreciated IVY dependency management as an option in gradle, publishing of artifacts is still will be supported however.

As far as 3rd party android project libraries, the standard option if not reconstituting them is to do a fork of the repo in your own git provider user space and than do a git module to that forked repo in your git repo-space. Why? Because than instead of being tightly coupled with every change on the master branch flowing to your app project its only coupled to a fork of the project at a specific point in time. And youavoid breakage by not deleting those forks from your git space repo but instead only update the git module references when you see a change in the 3rd party library that you in fact need, that way you keep breakage to a minimum.