On 16/09/2010, at 2:01 AM, Philip Crotwell wrote: > So today, as I seem to have done way too many times, I typed "gradle > eclipse" and got back: > > FAILURE: Could not determine which tasks to execute. > > * What went wrong: > Task 'eclipse' not found in root project 'XYZ'. > > > The question that popped into my head is "why do I have to add 'apply > plugin: eclipse' to the build.gradle file just to run the eclipse > task? The eclipse plugin in built in so gradle knows about it. I just > typed "gradle eclipse", so gradle knows I want the eclipse plugin to > run. "What we've got here is a failure to communicate!" :) > > So, I wonder if some or all of the built in plugins might be > "auto-applied" so that those tasks are available even if they are not > manually "applied". Of course external plugins need something to tell > gradle how to find them, and some plugins might require configuration > before they can function, but perhaps instead of a failure, gradle > could search the list of tasks in the built in plugins before giving > up? If it finds a match, apply the plugin then run the task.
I think this is a good idea. Certainly for tasks like eclipse, idea or wrapper it would make sense. Same for reporting tasks, and in the future, archetype-style tasks. We plan to do something in the Gradle 1.0 release to address this. There's a few related issues in JIRA: http://jira.codehaus.org/browse/GRADLE-781 http://jira.codehaus.org/browse/GRADLE-997 http://jira.codehaus.org/browse/GRADLE-1113 > > Along those same lines, if I have a project that has .groovy files > inside src/main/groovy, shouldn't that be enough to tell gradle that > it should apply the groovy plugin? Similar for java and scala. > Requiring the "apply plugin" to be manually specified in the > build.gradle seems redundant. It does. But then, it also seems like a risky strategy to go looking for source and automatically applying plugins based on what we find. Another approach might be a set of tasks which help you maintain the build. For example, we might add a task that inspects the source directories, and creates a build script with the appropriate plugins applied. Over time, this can get more sophisticated, so that it might, for example, compare an existing build script with the source directories and add or remove plugin declarations based on what it finds. Or dependency declarations, or source sets, or whatever. The idea here is to accept that some degree of redundancy is just a given, and to provide some way to synchronise the contents of the build file with the source tree. The synchronisation could happen in either direction. You could also think of IDE integration, and pom.xml/ivy.xml integration as a synchronisation problem: the same information is represented in multiple places where it can change, and we need some way to synchronise them all when changes are made. -- Adam Murdoch Gradle Developer http://www.gradle.org CTO, Gradle Inc. - Gradle Training, Support, Consulting http://www.gradle.biz
