Hans, Thank you for adding includeFlat to .4, I've configured a test project and it works as expected. I'm looking forward to dropping GANT from my project and integrating Gradle this week.
Thanks again, Dennis On Tue, Sep 9, 2008 at 2:57 AM, Hans Dockter <[EMAIL PROTECTED]> wrote: > 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 > > >
