Hans Dockter wrote:
Hi,
I have started to work on enabling the configuration of arbitrary
project locations and the project names. In the settings.grade file
one should be able to say something like:
include('virtualProjectPath', 'physicalProjectPath', 'projectName')
I think we need a domain model object which represents a project that
will be included in the build. Let's call it a ProjectSettings object.
An instance for each project in the build would be available for the
settings and gradle init scripts to mutate. It would have properties
something like:
- path (aka virtual project path)
- name
- parent project
- project directory (aka physical project path)
- build file name (or build file)
- build directory
Path and name would probably be immutable, though we might let you
change the name of the root project.
Settings.include(path) would create one of these and include it in the
build. It would have resonable defaults for the above properties, based
on the layout in effect (say project directory = root dir + path, build
file name = "build.gradle", build directory = root dir + path + "/build")
There'd be 2 overloaded Settings.include() methods:
ProjectSettings include(String path)
ProjectSettings include(String path, Closure configureClosure)
That is, I'd be able to do:
include 'api' {
buildFileName = 'api.gradle'
projectDirectory = root.file('../somewhere-else')
}
Possibly include() should be called addProject() or includeProject().
Given that Settings is a collection of ProjectSettings, and Project is a
collection of Tasks, and DependencyContainer is a collection of
Configurations, we should use a consistent pattern for how you add and
configure things in a container (ie addThing() or createThing()?).
There'd be a few other methods on Settings to manipulate the collection
of ProjectSettings, things like:
ProjectSettings getRootProject()
ProjectSettings project(String path)
void allprojects(Closure configureClosure)
I'm still thinking about the best way to marry this with the current
convenient definition of a hierarchical physical project layout.
I think the above solves this. If you call include(path), things
continue to work as they already do.
One other issue is how to do partial builds. For virtual hierarchies
there is no way to automatically find the root project if you are in a
subproject. My idea is to specify the rootproject with a command line
option. What do you think?
This makes sense when you cannot find the root project. However, for
certain layouts you could, if a layout has the concept of a RootFinder,
as Dennis suggests.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
