On 03/08/2011, at 10:28 AM, Adam Murdoch wrote:
> On 18/07/2011, at 10:42 AM, Luke Daley wrote:
>
>>
>> On 17/07/2011, at 9:32 AM, Eric Berry wrote:
>>
>>> I've run into this issue myself. Right now I'm having our developers
>>> download the plugin jar file and install it into gradle lib/plugins
>>> directory. But the buildscript method seems pretty standardized.
>>>
>>> I wonder if it could be automated more by adding something like:
>>> apply plugin: 'company-plugin', fromJar: 'url://to/company-plugin.jar'
>>>
>>> I was looking through the source recently, and I was thinking it might be
>>> possible to add something like this to the DefaultObjectConfigurationAction.
>>>
>>> Where it would download the jar to ~/.gradle/cache (or somewhere else), and
>>> then add a buildscript closure to the project pointing the dependency at
>>> the downloaded jar file.
>>>
>>> Afterwards applying the plugin.
>>>
>>> I'm not completely familiar with the Gradle source, but is something like
>>> this even feasible? If so, I can try and get something working over the
>>> next week or so and try to submit a patch?
>>
>> This thread and the “easy plugin integration” thread are highlighting that
>> there is a hole here.
>>
>> Before working on any implementations or even DSL modifications, I think we
>> need more thought and exploration of the core problem here. The best way to
>> do that is probably to explore people's use cases and see what patterns
>> emerge.
>
>
> As I see it, the basic problem here is that organisations need to make some
> build logic available to their teams, in a controlled way. The exact build
> logic that needs to be shared varies, but generally includes:
>
> * Information that the build needs to know about the organisation's
> infrastructure. For now, this means repository definitions, but might later
> include things such as resources for distributed build/test or deployment.
>
> * Configuration of the standard Gradle plugins, to define the organisation's
> convention. For example, changing the default source directories.
>
> * Making custom plugins available to the build.
I wonder if we can break this down to:
1. Provide an external mechanism for augmenting the classpath for build script
evaluation (i.e. a way to do what you can do in the buildscript block from
outside)
2. Provide an external mechanism to specify which plugins should be implicitly
applied to which projects in the build (using the augmented classpath)
3. Provide a way to “include” a script from a central location that does 1
and/or 2.
As for 3, I think we'd need two ways…
1. a significant block in the root build.gradle file, like buildscript{} that
is extracted and used to specify what to source in that does 1 and 2 from above
(the actual buildscript block would be evaluated after this, using the new
classpath)
2. some way to create a custom gradle distribution that either included a
script to do 1 and 2 above, or points to a script (probably via URL) that does
this
--
Luke Daley
Principal Engineer, Gradleware
http://gradleware.com
