Virtual Project Paths (a.k.a arbitrary multi-project layouts)

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

Virtual Project Paths (a.k.a arbitrary multi-project layouts)

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





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Virtual Project Paths (a.k.a arbitrary multi-project layouts)

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





Reply | Threaded
Open this post in threaded view
|

Re: Virtual Project Paths (a.k.a arbitrary multi-project layouts)

Adam Murdoch-2
In reply to this post by hans_d
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


Reply | Threaded
Open this post in threaded view
|

Re: Virtual Project Paths (a.k.a arbitrary multi-project layouts)

hans_d
Administrator
In reply to this post by hans_d
Hi Adam,

On Aug 29, 2008, at 2:44 PM, 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'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?

What about c.)?

> 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?

f.) is equivalent to c.) I guess.

- 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: Virtual Project Paths (a.k.a arbitrary multi-project layouts)

Adam Murdoch-2


Hans Dockter wrote:

> Hi Adam,
>
> On Aug 29, 2008, at 2:44 PM, Hans Dockter wrote:
>
>>
>> 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?
>
> What about c.)?
>

I think it makes sense. How would this work on the command line?


Adam

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Virtual Project Paths (a.k.a arbitrary multi-project layouts)

hans_d
Administrator

On Sep 12, 2008, at 12:28 AM, Adam Murdoch wrote:

>
>
> Hans Dockter wrote:
>> Hi Adam,
>>
>> On Aug 29, 2008, at 2:44 PM, Hans Dockter wrote:
>>
>>>
>>> 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?
>>
>> What about c.)?
>>
>
> I think it makes sense. How would this work on the command line?

May be by using s special separator. That way we could continue to  
mix, which is pretty cool I think.

For example:

gradle :<projectPath>*taskName1 :<projectPath>*taskName2  
clean :<projectPath>:taskName3

- Hans

--
Hans Dockter
Gradle Project lead
http://www.gradle.org





---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email