Hi Couple of thoughts...
This might be covered under your "- Generated source, or generated bytecode.", but we have several projects that use corba, so there is java that is generated by the idl compiler. So src/main/idl is used to generate src/main/java. In some sense I suppose it could be output into build/java instead and then run the java compiler there. Maybe that would require a "corba plugin". With corba, you also often have "impl" classes that are written by a person and extend the generated corba classes. I don't like mixing hand written code with generated code in the same directory. My solution so far has been to use a mulitproject idea with the generated code and impl code in separate projects with a dependency. It has always felt a little weird to have the idl project separate from the impl project, as well as two jars, as they are so tightly coupled, but that seemed the best solution at the time. Another case is code that is used in the build process, but not in the runtime. Things that would be called from build.gradle, but never used from the dist code. I am now writing some groovy code to do "helper" stuff for the build. It is big enough that I don't want it directly in build.gradle but it is unclear to me at this point where to put code like that. It needs to be part of a source release, but should not live in src/main/java or src/main/groovy. Also, if there were a standard "place" for this type of build helper code, it could automatically be added to the build classpath, making it much easier to use custom code within the build process. Lastly is the the case of what I would call "play" code. I often want to write some small piece of code to play with some feature. I want it to compile locally, probably with its own main(), but do not want it in the dist and it isn't a unit test. Perhaps it could be put in src/play/java and compile to build/play-classes. Perhaps that suggests a rule system, where src/XYZ/java is compiled by "gradle compileXYZ" and the results are put into build/XYZ-classes. src/main could be a special case so that gradle compile is the same as gradle compilemain and still goes to build/classes. Just an idea. thanks, Philip On Thu, Aug 13, 2009 at 5:38 PM, Adam Murdoch<[email protected]> wrote: > Hi, > > I'd like to figure out a bit of a design for the so-called 'source > directories' feature. Basically, this feature is about making the Java > plugin, and all the plugins based on it, more flexible in how java projects > are laid out, and what happens to the various source files that make up a > java project. > > I'd like to start with use cases we would need to solve. > > Right now a java project: > > - Has some production source files. These are compiled and assembled into a > jar or war. Optionally some unit tests or quality checks are run against > them. > > - Has some test source files. These are compiled and run as unit tests > against the production classes. > > This is all nice and simple. It works fine for, say, an open source library > project. However, I've not seen a decent sized java project where this is > sufficient. > > I'd like to find out about those use cases you might have where this simple > model does not work well. Here's some example use cases: > > - Multiple projects sharing the same source directory. For example, this > might happen when a legacy monolithic Ant build is chopped up into a bunch > of Gradle projects. > > - Production and test source in the same source directory. Not necessarily a > great idea, but some people do this. > > - Production source with an api and implementation. For example, you might > want to use different checkstyle rules for each, or javadoc just the api, or > you might want to end up with an api jar and an api + impl jar. > > - Test source contains test fixture classes which are used by other > projects. For example, you want to jar up your test classes and publish the > test fixture jar alongside the production jar. > > - Multiple test suites, each in a separate source directory and with > separate classpaths. For example, you might have functional tests or > performance tests which you don't want the 'test' task to execute. > > - Compile different parts of the source against different java versions. > > - Generated source, or generated bytecode. > > Anyone have any other use cases? > > > Adam > > > --------------------------------------------------------------------- > 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
