Hans Dockter wrote:
On Aug 22, 2009, at 12:41 AM, Adam Murdoch wrote:
Hans Dockter wrote:
On Aug 21, 2009, at 1:52 AM, Adam Murdoch wrote:
Hans Dockter wrote:
I have just submitted a new build structure for the Gradle build.
The Gradle build is now a multi-project build with a root project
and two subprojects.
root
- gradle-core (which contains everything except wrapper)
- gradle-wrapper
ATM root is doing user's guide, distribution, release and
integtest. The integtest are still part of gradle-core but
executed from root. Although this shows the enormous flexibility
of Gradle it probably should not remain like this.
How do we want to go from here? Some idea:
root (integtest (including dealing with the integ test sources),
distribution, release
- user's guide
- gradle-ui
- gradle-wrapper
- gradle-core
- plugins
-- osgi
-- jetty
-- eclipse
-- maven
-- ...
What should we do with the website? I'd much rather it were under
gradle-core/trunk, along with everything else.
That would make sense. We have to do the merging then, which is
quite painful as long as we use svn. But therefore we don't need to
specify the referring gradle working copy and manually build the
website docs. And the release could be truly 1-click (and not
2-click as it is now).
We have a few options other than making it a sub-project:
1. It is a stand-alone build, but because it is in the same source
tree as the main build, the path to the working copy can default to
something useful.
This is a good idea.
2. As for 1., plus we move the release stuff into an aggregating
build which co-ordinates building and publishing both the
distribution and the website.
This is even better. Although a bit awkward to implement as long as
Gradle can't aggregate multi-project builds.
3. As for 1., plus we add some way for the website build to trigger
the building of the artifacts it needs from the distribution build.
For example, we could provide a simple way to execute another Gradle
build:
task buildDocs << {
def buildResult = gradle.run(projectdir: gradleMainBuild, tasks:
'websiteDocs')
websiteDocsDir =
buildResult.gradle.project(':gradle-docs').websiteDocsDir
}
I think this is best way at the moment to start with.
Or we could add a way to register how to build an external dependency:
dependencies {
website group: 'org.gradle', name: 'gradle-docs' {
builtBy 'buildDocs'
}
}
task buildDocs << {
// run 'websiteDocs' tasks in main build
}
Some construct like the above is really cool to have for our
build-integration tool set. The builtBy task would then belong to
TaskDependency returned by website.buildDependencies.
I think for the website 3.) is fine. But for Java/Groovy/Scala
projects the buildBy clause would be excellent to have and easy to
implement. builtBy would be also very interesting for file
dependencies (you could use it for directory content then).
or perhaps you might register this at the repository level.
How would this look like and under what conditions would it be triggered?
Kinda similar to adding it to a dependency:
repositories {
local {
module(group: 'org.gradle', name: 'gradle-docs') {
builtBy 'buildDocs'
}
}
}
Then, any configuration which depends on ':org.gradle:gradle-docs:'
would include 'buildDocs' in the TaskDependency returned by
getBuildDependencies(). The benefit of this approach over adding it to a
dependency, is that the definition of how to build the module lives in 1
place, and can be used from multiple places. I'm guessing this option
would be awkward to implement.
My choice would be to use 3.) at the moment for the website stuff. I
would start with doing this if there are no objections.
Not from me.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
