On Fri, Aug 24, 2012 at 1:59 PM, Luke Daley <[email protected]>wrote:

>
> On 24/08/2012, at 8:16 AM, Szczepan Faber wrote:
>
> There is even more to it. There is obviously need for what we now model as
>> our internal tasks. You don't want to ask people to add the dependencies
>> report plugin because most of the time they don't want anything special
>> (possibly similar to the ide use case). Or take the projects task. I think
>> there is no argument that there is an important use case behind the
>> internal tasks. But the internal tasks are not a nice solution for this. I
>> think it is an unnecessary additional concept which is not extendible, that
>> solves this problem for the most obvious scenarios in an ad hoc way. With
>> auto applying plugins we can get completely rid of it and any task can now
>> be used this way. When we added internal tasks we always considered it an
>> ad hoc solution and knew that they will be replaced by auto applying
>> plugins some day.
>>
>> Another good use case is the build-announcement plugin. I can of course
>> apply it in the init.gradle in user.home for all builds. But I might want
>> to use is only for some projects, I might want to use an alias that runs
>> gradle with the build-announcement plugin, etc... Which leaves me with one
>> question. How would we auto-apply a plugin that has no tasks?
>>
>> I'm sure there will be a significant set of more very interesting use
>> cases. It is another important piece of the toolkit story where we can
>> embrace the unanticipated and make custom requirements extremely convenient
>> to deal with.
>>
>
> I agree entirely. It would be extremely useful. Auto-applying
> plugins/tasks might also improve performance / memory consumption of the
> build as we don't build model for certain things (like ide) with every
> configuration phase.
>
>
> That's assuming there is no IDE configuration required right?
>

yes. In so far we will hopefully have smarter options in the future to
avoid unnecessary configuration.

Hans


>
> --
> Luke Daley
> Principal Engineer, Gradleware
> http://gradleware.com
>
>

Reply via email to