Why not just check in the gradle jars to maven central? That way you could even
support oddball scenarios like building a plugin for 0.9.3 while using M4.
On Aug 9, 2011, at 1:52 AM, Luke Daley wrote:
>
> On 08/08/2011, at 10:24 AM, Adam Murdoch wrote:
>
>> The gradleApi() dependency was never supposed to expose the plugins, only
>> the core. The plugins were unintentionally included in previous versions,
>> and in milestone-4, gradleApi() was changed to include only the core API
>> (ignoring the fact that gradleApi() also includes all the runtime
>> dependencies of core - that is a separate problem).
>>
>> We'll probably do as you suggest, and add some methods to declare
>> dependencies on the plugins. I think we should bust it up, so that you
>> declare a dependency on particular plugins, rather than all the Gradle
>> plugins lumped together. Perhaps something like:
>>
>> dependencies {
>> compile plugin('java')
>> }
>>
>> Another option is to deprecate gradleApi() and localGroovy(), and replace
>> them with a repository implementation that knows how to find stuff in
>> $gradleHome/lib:
>>
>> repositories {
>> gradleDistro()
>> }
>>
>> dependencies {
>> compile 'org.gradle:gradle-core:${gradle.gradleVersion}'
>> compile 'org.gradle:gradle-plugins:${gradle.gradleVersion}'
>> }
>>
>> I don't think I like this approach.
>
> For my money, that's better than a special notation.
>
> --
> Luke Daley
> Principal Engineer, Gradleware
> http://gradleware.com
>
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
