I'm a little wary about the notion of adding another option on the command
line to determine the layout at runtime.
If you went with 2 default layout strategies which would cover 99% of the
use cases and then allow definition named layout strategies which could be
set in settings files on the project (and sub-projects) like:
layout('foo')
I do like the idea of virtual paths, but I think they should be pushed into
a strategy and easily overridden in settings files if necessary.
The layout would have a searcher to find the project root.
The problem with alternative project layouts, if a project using gradle was
open sourced, the layout strategy would need to be distributed with it. With
two default strategies, most uses cases would be covered and this would not
be as much of a worry.
On Fri, Aug 29, 2008 at 8:44 AM, Hans Dockter <[EMAIL PROTECTED]> 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'm still thinking about the best way to marry this with the current
> convenient definition of a hierarchical physical project layout. 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?
>
> 1.) Execute a specific task of a project from anywhere within the
> multi-project hierarchy.
> a.) Physical Hierarchical Layout (PHL): gradle :<projectPath>:<taskPath>
> b.) Virtual Layout (VL): gradle -R<fileRootProjectPath>
> :<projectPath>:<taskPath>
>
> 2.) Execute a task based on name matching in a subproject hierarchy:
> a.) PHL: Go to the subproject dir and type gradle <taskName>
> b.) PHL: From anywhere: gradle -p<fileSubProjectPath> <taskName>. But we
> have to specify the physical path of the subproject here.
> c.) PHL: From anywhere within the multi-project hierarchy via Gradle
> project paths. This is not possible yet. Should we enable this?
> d.) VL: Go to the subproject dir and type gradle -R<fileRootProjectPath>
> <taskName>
> e.) VL: From anywhere: gradle -R<fileRootProjectPath>
> -p<fileSubProjectPath> <taskName>. But we have to specify the physical path
> of the subproject here.
> f.) VL: From anywhere within the multi-project hierarchy via Gradle project
> paths. Should we enable this?
>
> Thoughts?
>
> - Hans
>
> --
> Hans Dockter
> Gradle Project lead
> http://www.gradle.org
>
>
>
>
>
