> > 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. Cheers! -- Szczepan Faber Principal engineer@gradleware Lead@mockito
