Hi, I've submitted an implementation of the flexible layout.
- The settings object now offers the methods: include and includeFlat. These are convenience methods for mapping from a physical hierarchical or flat layout. The include method behaves as before. The include flat method takes folder names which are at the same level as the root project. Obviously we cn provide here many more conveniences in the future, for example working with wild cards and offering includes/excludes for projects.
- There is a new class called ProjectDescriptor (it is equivalent what Adam has proposed as ProjectSettings, I just wanted to avoid a plural). The ProjectDescriptor objects form a tree with which you can assemble arbitrary local physical locations to a Gradle multi-project build. This class is missing two properties from Adam's proposal. One is buildFileName, which I will add soon. The other is buildDir. As buildDir can be set in the build.gradle file I left it out.
- We have the following process now: The locaton where Gradle finds the settings file is the settings dir. The settings object created out of the settings file has always a rootProjectDescriptor. The default for this root descriptor it, that its project dir is the same as the settings dir and its name is the same as the name of the settings dir. Both properties can be overwritten in the settings file.
- Finding the settings file: There is now a class called DefaultSettingsFinder which has a list of find strategies. At the moment this list is not configurable for the user and contains the MasterDirFindStrategy (looking for a dir called 'master') and the ParentDirFindStrategy (in this order). If we trigger the build from the root project this is not an issue but becomes relevant if we are in a subproject (partial builds). I have also implemented a SameLevelDirFindStrategy but removed it from the default list as it sometimes turned single project builds into multi-project builds (which can always be avoided by using the -u option). In our discussion on this topic the idea was to define strategies in a user home config file. As the layout is something project specific, this configuration in the user home would map a find strategy to a project, wouldn't it?
- There a two kind of multi-project builds. The classic one, which is tightly coupled and where the subprojects belong to one and only one multi-project build. For this common scenario, it might also makes sense to offer that you can specify (or configure) the find strategy in each subproject. This would provide the best out-of-the-box experience for multi-project builds not fitting into the default find strategies.
- Hans -- Hans Dockter Gradle Project lead http://www.gradle.org --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
