Philip Crotwell wrote:
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.
I think what we could do is introduce the concept of generated source
into the model, so you could declare which source code is generated, and
which task(s) generate it. You would be able to do this for production
source or test source.
Then, the compile task would take care of executing the generation tasks
before compilation is done, and include both the generated and
hand-written source in the compilation. The other tasks which operate on
source, such as the javadoc, checkstyle, and test coverage tasks would
ignore the generated source and operate only on the hand-written source.
If we had this concept, then it would be relatively simple for someone
to write a corba plugin, which configures things so that the source
generated by the idl compiler is declared as generated source.
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.
As John pointed out, you can use the buildSrc directory for this.
There's a little bit about it in the user guide:
http://gradle.org/0.7/docs/userguide/organizing_build_logic.html
The $gradleHome/samples/java/multiproject sample contains an example.
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.
This is a very interesting idea.
The solution to the layout problem that I've been thinking about
involves introducing the concept of a 'source set'. This is basically an
object which you can use to define a bunch of source which is compiled
together, along with the compile and runtime classpaths and a bunch of
other attributes. A source set would have a name, say 'main' or 'test'.
When you declare a source set nnn, Gradle would add a compileNnn task,
and optionally other tasks like jarNnn, checkstyleNnn, javadocNnn, etc.
This would combine nicely with your idea, where we basically discover
the source sets for a project. Gradle (or more likely a plugin) would
automatically define a source set for each src/nnn directory. Under each
src/nnn, you could add src/nnn/java, src/nnn/resources, src/nnn/groovy,
src/nnn/scala, (or even src/nnn/idl) as needed.
We would use the name of the source set to set up a bunch of defaults:
- Classes dir defaults to $buildDir/classes/nnn
- Compile classpath defaults to the nnnCompile configuration
- Runtime classpath defaults to the nnnRuntime configuration
Or even interesting conventions like if the source set name ends with
'test', we add a test task for the source set.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
