I have refactored our build a little bit.
There is now an additional subproject gradle-docs for creating
userguide, javadoc, groovydoc and the samples.
The root project is dependent on gradle-docs in that it needs the
whole docs for the dist zips as well as the samples for the
integration tests. Right now the dependency between those projects is
hand-crafted. This means the dists have direct dependencies on task of
gradle-docs. Eventually they will turn into project dependencies.
I have removed the exploded dist stuff. The zips do now directly
collect the files from where they are (as far as the current archives
api allows this). One important improvement is that the prefix of the
ZipFileSet is now lazily evaluated. Therefore we can now configure the
zips at configuration times (which we didn't do before as the version
property is set after configuration time) which makes things much
easier to maintain and to read. The wrapper project is no longer part
of the samples we ship. It is now only created in the intTestImage for
testing the wrapper. It contains absolute paths of the machine that is
used for the build. We don't want to ship this.
The whole thing is work in progress. There are a couple of open issues
where I'm wondering what best practices are. Anyhow, I think the build
is now easier to understand.
I hope we can manage soon to make our archives fully understand
filecollections (including working with prefixes) and automatically
add the filecollection dependencies. It should also be easy to reuse
zipfilesets across different archives.
- Hans
--
Hans Dockter
Gradle Project Manager
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
