Hi, One problem we have with our IDE plugins at the moment, is that generated resources are not available in the IDE. By default, any resources generated by the build are not available on the classpath when you, say, run your tests.
It would be nice to deal with this better. Here are some possible approaches (note: I'm leaving out test resources here, but we would use the same approach for all resources): 1. Change the IDE plugins so they add build/classes/main to the appropriate classpath in the IDE, after the IDE's compiler output directory. 2. Change the Java plugin so that resources end up in build/resources/main, and classes end up in build/classes/main, and the IDE plugins so that they add build/resources/main to the appropriate classpath in the IDE, before the IDE's compiler output directory. 3. Encourage the build author to generate resources into build/generated-resources/main, and add this to the appropriate classpath in the IDE, before the IDE's compiler output directory. 4. Change the IDE plugins so that they add a task which executes after processResources, and then copies anything in build/classes/main which does not have a corresponding resource in src/main/resources to some directory, say ide/resources/main, and add this directory to the appropriate classpath in the IDE, before the IDE's compiler output directory. One downside to options 1 and 2 is that some files will appear twice on the classpath - once in the directory under build/ and a second time in the output directory of the IDE. Option 2 is better, in that only static resources appear twice, rather than classes and resources in option 1. The big downside to option 3 is that it is dependent on the build author knowing how the mapping scheme works, and being careful to copy static resources into build/classes/main and generate dynamic resources into build/generated-resources/main. To me, this is a deal breaker for this option. Option 4 is interesting, in that it produces the most accurate classpath in the IDE, but requires some extra copying to be done in each build (only if an IDE plugin is applied). I think my preference is either option 2, or option 2 + option 4 combined (that is, we should split classes and resources regardless). One downside of all these options is that the resources are not 'live' in the IDE, and require that the build be executed before, say, running the tests. With some deeper IDE integration, we should be able to solve this problem. Without it, I'm not sure how we can tackle this. On the other hand, all of these options are better than not having the generated resources available in the IDE. Thoughts? -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
