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
