On Aug 21, 2009, at 3:08 AM, 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.
On Thu, Aug 20, 2009 at 7:49 PM, Adam Murdoch <[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.
I agree.
- 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.
I agree.
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? 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 guess what you have mentioned above regarding docs and reports.
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. 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).
I'd be very interested in that.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
