On Sun, Jul 17, 2011 at 5:42 PM, Luke Daley <[email protected]>wrote:
> To that end, it would be useful to get some information on the nature of > your project and how you are using the plugin mechanism to solve build > problems, including the development workflow. > > Sure thing. The main problem for our project is common setup. We have roughly 12 separate projects that are actively developed and continuously deployed to various servers and hosts. Each project should build roughly the same way and produce the same kinds of artifacts so the deployment process can be more automated. I've set up a few "corporate" plugins which all get bundled into a single 'corp-plugin.jar' which developers are responsible for downloading and installing. Or they can download the source for the corp plugin and run 'gradle installPlugin'. They then use the plugins in their projects by applying the ones they need. Eg. We have a base 'company-corp' plugin which sets some common settings and adds a few common tasks, and a 'company-api' plugin which adds some tasks specific to RESTful webservices. For instance, all new Java development must use Java 1.6 or later, so I set 'sourceCompatibility = JavaVersion.VERSION_1_6'. We also all use either IDEA, or Eclipse so the 'company-corp' applies both those plugins. Furthermore we have a company maven repo (artifactory) which all dependencies must be proxied through, so I configure the repository, the uploadArchives task and maven plugin to work with it. I use plugins for this because everything can be bundled together and installed very easily. Working with common scripts and the 'apply from' would require extra hosts to make them available to other developers. It would also require developers to remember and type (or copy/paste) a lot more which can easily lead to typos and lost time fiddling with the build system. The main problem with plugin jars is that whenever there's a new version, it has to be downloaded and installed manually. The syntax I described earlier would let me keep the latest version in a single URL, allow developers to only have to remember a single location, and still maintain a single line addition to their build scripts. I came from a Maven2 development environment, and I made the decision to move to Gradle for this new company. One thing I hated dealing with when working with Maven was the "base" setup. We had various "template" projects in SVN so that developers would just download one, copy the base pom.xml file and then change it to fit their needs. Inside the base pom had the company repository, and various other settings. Or use archetypes which still resulted in a base pom file with those settings. I wanted to avoid this as much as possible, and the Gradle plugins let me do that very easily. They let me abstract those common settings so that developers don't have to think about them, they just "apply plugin: 'company-corp' ", and start developing. Honestly, I feel gradle is one of the best decisions I've made for the company thus far. -- Learn from the past. Live in the present. Plan for the future. Blog: http://eric-berry.blogspot.com jEdit <http://www.jedit.org> - Programmer's Text Editor Bazaar <http://bazaar.canonical.com> - Version Control for Humans
