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? -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
