Eric Berry wrote: > > 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. >
I'll chime in here as well with our use case. I am rewriting our company's (Netflix) common build framework. The current implementation is a collection of Ant scripts and supporting libraries delivered as a small directory tree from the SCM (Perforce) depot. The supporting libraries include Ivy and Groovy which we leverage heavily, and thus influenced my desire to move to Gradle which also uses these. Seems like a good fit to me. We use this common build framework from several hundred different individual projects that build, test and release Java libraries and applications. Most of the projects' build.xml files are little more than one line of import, with all the work handled by the Ant targets in the framework. Updates to the framework are done by integrating a beta branch to the main tool tree that all developers and Jenkins jobs then get sync'd into their workspaces. My first pass was to replace a bunch of the Ant with Gradle+Groovy scripts and that worked well enough for some simple use cases. Now I have moved the work to a plugin that can do all the things we want, such as setting up the repositories to our internal Artifactory, import ivy.xml files, query the repo for current module status, define standard source layouts, provide tasks for custom artifact types, handle releases, etc. I can see two ways of delivering/consuming our plugin jar: 1) via a tools repo in our Artifactory instance (normal use), and 2) built from source in its development project location (for tools folks and brave users). I think a custom init script in a wrapper could allow this to work, with an env variable or other setting used to select which version of the plugin to get and where to get it from. --carl -- View this message in context: http://gradle.1045684.n5.nabble.com/Ideas-for-simplifying-the-bootstrapping-of-plugin-loading-tp4588130p4614039.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
