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 more flexible around how java projects are laid out, and what
happens to the various source files that make up a java project.
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, for many java projects I've seen this is not
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 examples:
- Multiple projects sharing the same source directory. For example, this
might happen when a legacy monolithic Ant build is being chopped up into
a bunch of Gradle projects.
- Production and test source in the same source directory.
- 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 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 some 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
