Paul Speed wrote:
Adam Murdoch 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.
This is the way the meta-jb (my project) builds are setup. It used to
be one big monolithic ant build with lots of different targets and now
I've superimposed gradle projects onto it. (Interesting side-note:
the reason I've abandoned maven here is because the pom.xml's produced
were uglier than gradle's nice clean ones.)
In some cases, I could have moved things around but some of these
projects are so small and for some things it's a lot easier to
navigate around one tree than a dozen different full-depth trees.
For our project, in the root we have:
/src/main... etc.
/std/build.gradle, settings.gradle
/std/core, /std/util, etc.
/ext/
/ext/extract, /ext/util, etc.
"std" contains all of the main sub-projects that are managed and
versioned together. The dependencies in those sub-projects are of the
project( ":foo" ) variety.
"ext" contains separately released projects that are independent.
They depend on other project artifacts just like any other dependency
using the maven-style gradle-ized coordinate groupId:app:version.
How do these projects find the artifacts from the other projects? Are
you using a local or remote repository?
In both cases, all of the build.gradle files have sections like:
compile {
include( "org/progeeks/foo/**" )
}
The only odd thing is configuring resources like that seems to use an
entirely different syntax.
Not sure what you mean by this.
For the most part, this works great... until it doesn't. And when it
doesn't one gets very strange behavior.
Since javac will happily compile anything that it finds the source for
if it doesn't also find a class on the classpath, and since we're
building everything out of the same source tree, any mistakes in
dependency specification (or "excludes" in some cases) will cause
those .class files to be duplicated in the local jar.
This can also have a cascade effect. I think I've seen cases where if
a project's dependencies include an old version of a .class file for a
class they shouldn't have and the compiling project is dependent on a
newer version then it will get recompiled.
At any rate, it should be easy to see that one little mistake can
cause some very strange classpath behavior in trying to figure out why
updating "util" isn't causing a certain class to update.
I'm not sure this is a problem gradle can solve but it's something to
be aware of for any going down this road.
You can switch this off by providing an empty sourcepath to the
compiler. Gradle should really do this by default.
I think in your case, we could simplify things by:
- switching off the implicit compilation, so that the compile task fails
if you've missed an inter-project dependency.
- providing a single place for you to define the include and exclude
patterns for the project, so that compile, processResources,
compileTests, jar, javadoc, checkstyle, etc all use the same set of
includes and excludes.
Anything else?
Actually, is there a way to limit the classes included in the build
jar file? If I could give it a similar set of include()/exclude()
lines as in the compile {} configuration then at least the errors
wouldn't propagate silently.
You can do something like:
jar {
fileSet(dir: classesDir) {
include 'some pattern'
exclude 'some pattern'
}
}
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
