Justin, Thank you very much for sharing. I'm going to play around with this some and make it work for our needs.
This is a great idea and will allow me to control the version of Gradle our developers use as well. Cheers, Eric On Thu, Apr 12, 2012 at 10:52 AM, Justin Ryan <[email protected]> wrote: > The approach I've taken is using an init script to bootstrap our > corporate repository and to add the plugin to the path, but not > applying it. The key is to have a special gradlew to load this init > script implicitly. I then have every project use this gradlew, which > in my case is centrally located. If done properly, my users just have > to have this in their build.gradle, if they choose to use my plugin: > > <code> > apply plugin: 'nebula' // NEtflix BUild LAnguage > </code> > > There are a few way to inject an init script, but none of them worked > for me. The documented way is to put them in the init.d script of the > distribution, but since I'm using gradlew, it's downloading the > distribution, and I don't want to be in the business of mucking with > the distribution. So, I have a small modification to gradlew to add > the init script itself: > > 68a69 > > INITPATH=$APP_HOME/gradle/wrapper/init.gradle > 117a119 > > INITPATH=`cygpath --path --mixed "$INITPATH"` > 165c167,171 > < exec "$JAVACMD" "${JVM_OPTS[@]}" -classpath "$CLASSPATH" > org.gradle.wrapper.GradleWrapperMain "$@" > --- > > if [ -f $INITPATH ]; then > > exec "$JAVACMD" "${JVM_OPTS[@]}" -classpath "$CLASSPATH" > org.gradle.wrapper.GradleWrapperMain --init-script $INITPATH "$@" > > else > > exec "$JAVACMD" "${JVM_OPTS[@]}" -classpath "$CLASSPATH" > org.gradle.wrapper.GradleWrapperMain "$@" > > fi > > I then plop an init.gradle file in the gradle/wrapper directory. The > file looks something like this: > > rootProject { > allprojects { > buildscript { > repositories { > maven { url 'http://artifacts.netflix.com/build-gradle' } > > dependencies { > classpath(group: 'netflix', name: 'nebula', version: > '1.3') > } > } > } > } > } > > The one problem I've found is that the buildscript repositories > defined here won't be available in the build.gradle, so it has to be > redifined if they want to add other plugins to classpath. > > Eric, in your case you could add all three plugins to the classpath, > and leave it up to the users to apply them. > > -justin > > On Thu, Apr 12, 2012 at 10:15 AM, Eric Berry <[email protected]> wrote: > > Sorry, the reason we'll have to stick with the "apply from" script is > that > > the buildscript block is just too much boiler plate for me. We have > dozens > > of projects and many (95%) of them have 3 sub-modules that apply > different > > plugins to each module. They would all require the same exact 5-10 lines > of > > code at the top of all of their build scripts, and this just isn't > > acceptable to me. > > > > The "apply from" scripts at least keep everything in a single line of > code > > for each plugin the developer wants to use. Making it a lot more > > maintainable for me. > > > > > > On Thu, Apr 12, 2012 at 1:14 AM, Adam Murdoch < > [email protected]> > > wrote: > >> > >> > >> On 12/04/2012, at 9:18 AM, Eric Berry wrote: > >> > >> Hi Adam, and Peter, > >> Thank you both for the quick response. > >> > >> Adam, guess we'll have to stick with the "apply from" scripts that have > >> the extra code to check to see if the plugin is installed. > >> > >> > >> You shouldn't have to. Gradle will check this for you. You can just do: > >> > >> buildscript { > >> repositories { mavenRepo url: "…" } > >> dependencies { classpath "com.chegg.corp.gradle:chegg-plugin:12.2" } > >> } > >> apply plugin: 'chegg-corp' // or apply plugin: > >> com.chegg.corp.CheggCorpPlugin > >> > >> > >> -- > >> Adam Murdoch > >> Gradle Co-founder > >> http://www.gradle.org > >> VP of Engineering, Gradleware Inc. - Gradle Training, > Support, Consulting > >> http://www.gradleware.com > >> > > > > > > > > -- > > 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 > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > -- 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
