I agree with phillip on this one... My preference would be gen srcs are under build... And all artifacts under build should be ignored by the version control sys. I would expect a clean separation between stuff I created and want to manage thru dvcs and stuff that can easily be created by the build tool.
Sent from my iPhone On May 10, 2011, at 8:06 AM, Philip Crotwell <[email protected]> wrote: > I really like the idea that ANYTHING automatically generated goes into > the build dir. There is no reason that a src directory in the build > dir can't be a first class citizen and used by an IDE, it is just a > subdirectory after all. But it is important, imho, to separate "hard > to recreate" stuff from "trivial to recreate". My mantra is that > things outside of "build" a person created and I need to worry about, > things inside "build" can be easily recreated by gradle and so gradle > worries about them. If you blur these lines then you end up editing a > auto-generated file that is later overwritten or losing something > important because it wasn't in version control. Or maybe worse, > putting stuff into version control that doesn't need to be there and > messing up the up to date checks. > > just my $0.02 > Philip > > On Mon, May 9, 2011 at 11:46 PM, mraccola <[email protected]> wrote: >> To answer your specific questions: >> >> >> Adam Murdoch wrote: >>> >>>> * I'm not so sure generating files into the "build" directory is a good >>>> idea >>>> either. Why not treat these things like 1st class source folders and put >>>> them under "src". If not, why not put them under another top level >>>> folder...say "genSrc". >>> >>> Why do you think this is a good place for them? That is, what's special >>> about generated resources, so that they should end up in a separate >>> directory to all the other generated stuff (eg classes, jars, test >>> reports, zips, etc)? >>> >> >> They just seem like additional source (or resource) folders to me. They are >> often needed in order to compile the source or run the tests. Since we are >> talking about IDE support here we have to assume that the source code may be >> build by the IDE's builder instead of only with Gradle. We have to assume >> that users will be running unit tests from within the IDE instead of only >> with Gradle. Therefore, generating the folders so they can be processed by >> tools other than Gradle is the focus. >> >> >> >>> The Java plugin does support this stuff already - you just need to >>> configure it appropriately. We do want to add the concept of generated >>> source at some point, to reduce the amount of configuration you need to >>> do. And maybe the concept of generated resources, too. But, for now, all >>> we've really done is to allow you to configure a source set to have >>> multiple output directories, which need to be aggregated into a classpath. >>> You can use these directories for whatever purpose you like, and by >>> convention, there's one for the compiled classes ad one for the processed >>> static resources. >>> >> >> Yes, I understand the flexibility of the Java plugin and the source set >> concept. In fact I am using it in my own build...see below. I'm sharing >> these opinions in the hope of validating (or discrediting) my approach. >> >> >> >>>> In either case: >>>> >>>> * Gradle would wipe out the contents of these directories when the >>>> "clean" >>>> task was run. >>>> * Gradle would generate the files for the java directories BEFORE the >>>> appropriate "compile***" or "process***Resources" task was run. Gradle >>>> would compile or process these files just as it does the static files. >>> >>> Why do you want this to happen? >>> >> >> I'm coming from the perspective that the code generation task executed by >> Gradle is going to generate *source* files. Compiling the source files into >> class files (or processing resources) can easily be handled by the existing >> tasks (e.g. compileJava, processResources). All Gradle needs to do is >> append the folders which contain the generated source to the existing >> sourceSets. Here is an example of what I am currently doing in my Gradle >> script: >> >> >> sourceSets { >> main { >> java { >> srcDirs "genSrc/main/java" >> } >> resources { >> srcDir "genSrc/main/resources" >> } >> } >> test { >> java { >> srcDir "genSrc/test/resources" >> } >> } >> } >> >> task codeGen // some code generation here >> >> compileJava { >> dependsOn codeGen >> } >> >> >> >> >>>> * Gradle would add these folders to the IDE classpath. >>> >>> Should we add the generated source, or the classes compiled from the >>> generated source? >>> >> >> The generated source. The way I'm thinking, the folders containing the >> generated source are just additional folders in the source set. They can be >> added to the IDE (via the IDE plugin) as a source folder. Then the IDE's >> builder will compile the source on its own. I believe this is superior to >> having the IDE work with some classes which were compiled by an external >> process...Gradle in this case. >> >> -- >> View this message in context: >> http://gradle.1045684.n5.nabble.com/using-generated-resources-in-the-IDE-tp4363800p4383628.html >> Sent from the gradle-dev mailing list archive at Nabble.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 > > --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
