>Generating directly into build/classes seems wrong to me I agree.
Eventually, we decided that we'll go for option #2 with one amendment: the resources output dir will be *after* the ide output dir. This way static resources will be 'live' yet we'll solve the problem of generated resources not on the path. The trade-off is that resources will be twice on IDEs path :/ Cheers! Szczepan On Mon, May 2, 2011 at 7:38 PM, Philip Crotwell <[email protected]> wrote: > One thing you might consider while solving this "resources" problem is > to go one step back and ask what the convention for where generated > anything should go is, be it source code or resources. Generating > directly into build/classes seems wrong to me. A good convention might > be an analog of the src directory inside of build so that tasks that > generate source code or resources have a standard place to put it. > Code or resource generating tasks put stuff into directories like > build/generated/main/java or build/generated/test/resources and then > java plugin is responsible for merging into build/classes/main or > build/classes/test. As a bonus the IDE has a well know place to look > for stuff that is not in src/main/resources. > > I just feels to me that generating content is a separate step from > managing the build/classes directory and it is better for tasks to > avoid mixing those two. > > just my $0.02 > Philip > > On Sun, May 1, 2011 at 8:55 PM, Adam Murdoch > <[email protected]> wrote: >> 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 >> >> > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
