John Murph wrote:
I don't fully understand the consequences of what you are suggesting
here, so I just want to issue a few concerns that may or may not be
valid. Remember, for our project we have about 40 different
sub-projects and expect that to grow to maybe 100 over the next year
or so. Those numbers results in some different concerns that 4 or 5
sub-projects.
What are the relationships between the different projects? Are they all
independent? Are they all aggregated into a single product? Somewhere
between the two?
My suggestions below are really for a set of projects which are grouped
together into a single deliverable. It just so happens the Gradle build
only has 1 such group (for now).
On Thu, Aug 20, 2009 at 7:49 PM, Adam Murdoch <[email protected]
<mailto:[email protected]>> wrote:
- The groovydocs don't include anything from gradle-wrapper.
- The javadocs don't include anything from gradle-core.
What we want here, I think, is a single javadoc task and a single
groovydoc task in the root project, whose source is the union of
the source from each subproject. We don't care about the
javadoc/groovy doc from each individual subproject.
As long as I can build the javadoc/groovydoc for a single project,
then I agree that all included subprojects should be automatically
"linked" in. We are doing that right now, and it's not a very large
change.
- The unit test reports are split up.
I'd like a single, unified test report. This will also be true of
a code coverage report. And probably all of the code quality reports.
What I would like is a single report page that shows a summary (I'm
not sure what going into this summary...) and then links to the
individual reports for the subprojects. Putting all the info into one
report would be overwhelming for us. Especially when the modules get
built in a piecemeal fashion.
We could do something like that. Whichever way we go, it's the job of
the report to present a summary and let you drill down to the details.
Also, it feels like we're missing a plugin which takes care of
aggregating a bunch of java projects into a single project, which
is basically what the root project build is currently doing.
What are you thinking here?
A common pattern in multi-project builds is that a large product is
broken up into a number of Java projects which produce a bunch of jars
and other artifacts, and that an aggregating project takes these
artifacts and assembles them into a number of distributions. The
aggregating project generally will have no production source of its own,
though it may have some integration tests. The aggregating project may
be the root project, as it is in Gradle's build, or it may be a sibling
of the Java projects. There may even be multiple aggregating projects,
each of which combine different sets of contributing projects into
different artifacts.
I think a plugin which understands this pattern and takes care of the
bulk of the 'how' would be really valuable:
usePlugin('project-bundle')
dependencies {
dist project(":some-project") project(":some-other-project")
}
This could then add a bunch of tasks, such as:
gradle zip, tar, tgz - generates a zip/tar/tgz with the jars + runtime
classpath of each project in the dist configuration
gradle build, buildDependencies, buildNeeded - similar to those for the
java plugin
gradle javadoc - generates the javadoc for the union of the APIs of
projects included in the distribution
plus probably a bunch which a java project gets: clean, test, check
I'm not sure much of our "glue" code in the root project would be
common. I haven't looked much at what Hans did for Gradle's build, so
maybe there is some I'm just not noticing.
I think heaps of what the root project does is reusable. For example:
Generic multi-project build:
- Injecting shared versions of dependencies
- Various lifecycle tasks which delegate to the corresponding tasks in
all subprojects
- CI build does clean build and verify of all subprojects
Multi-project Java build:
- Unified test and code quality reports for all subprojects
Aggregate multi-project Java build:
- Unified javadoc and groovydoc for API of all contributing projects
- Assemble distribution containing artifacts from all contributing projects
- Run integration tests against distribution
- Aggregating project has no production source, may have integration
test source.
This describes pretty much all the multi-project builds I've worked on.
It feels to me like there's some goodness to be packaged up into a
plugin or two here.
We need to give you guys some stats about our build as it stands right
now... I'll try to remember to get that for you soon. Things like,
number of classes and lines of code in buildSrc module; lines of code
in settings.gradle and our root build.gradle; average lines of code in
subprojects' build.gradles.
This would be cool.
It might surprise you how much we are doing in buildSrc and our root
build.grade and how little we are doing in our subprojects'
build.gradles. The idea is that with such a large number of
subprojects, we want their build.gradles to define what's unique about
them, not provide actual behavior (unless it's very special case
behavior).
This is a good approach.
Adam
