Flexible Layout

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Flexible Layout

hans_d
Administrator
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


Reply | Threaded
Open this post in threaded view
|

Re: Flexible Layout

dportello
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 <[hidden email]> 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