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
