arbitrary project layouts

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

arbitrary project layouts

Adam Murdoch-2
Hi,

I would like to start talking about 'arbitrary project layouts': what
that means, how we might solve the problem, and what can we do to move
towards the solution.

To me, it means being able to control the location of any file or
directory that gradle uses to load stuff, cache stuff, and generate
stuff. It also means having reasonable defaults for all of these things,
so I don't need to care if I don't want to.

Currently, the locations for each project are:
- project directory
- build file location
- build directory
- build file cache directory

There's also name and path for each project. These aren't locations as
such, but their default values are determined by locations, and there's
no way to override their defaults.

Additionally, the locations for the build (or maybe the root project):
- root directory
- settings file location
- settings file cache directory
- inter-project build resolver directory
- ivy cache directory
- wrapper dist cache directory
- probably some other things like default imports file(s),
plugin.properties, etc.

I'd like to be able to declare most of these locations in a file (or
files) . Then I can do things like check them into source control and
have the same layout on multiple machines, or share the same layout
between several people. Even better if those files are scripts so that I
can write code to declare my layout.

Overriding default locations from the command line is not really
something I want to be able to do, but I guess it should be possible for
most of the above locations.

The obvious place for most of these locations is in the settings file.
Some don't really make sense there (eg settings cache dir). One option
for these would be to add a gradle init script in gradle user home which
can override pretty much anything.

The things that make sense to do through the settings file are:
- build resolver directory
- ivy cache directory
- for each project:
  - name
  - path (not for the root project)
  - project dir
  - build file
  - build dir

I'll leave it for another email to discuss how I think this might work,
and how the command-line might work.


Adam

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: arbitrary project layouts

dportello
This sounds great, almost exactly what I was pondering. I think it might make also sense to have two sets of defaults, a hierarchical and flat layout which could be detected by Gradle. Looking through the source code yesterday I was contemplating how you could provide alternative layouts and have them picked-up automatically when invoking a build from any directory (sub-project).

Also, it might make sense to have a series of named layouts predefined in a gradle_home settings file/script which could be referenced from any project settings file, the two defaults being "flat" and "hirearchical".

-Dennis






On Fri, Aug 29, 2008 at 2:50 AM, Adam Murdoch <[hidden email]> wrote:
Hi,

I would like to start talking about 'arbitrary project layouts': what that means, how we might solve the problem, and what can we do to move towards the solution.

To me, it means being able to control the location of any file or directory that gradle uses to load stuff, cache stuff, and generate stuff. It also means having reasonable defaults for all of these things, so I don't need to care if I don't want to.

Currently, the locations for each project are:
- project directory
- build file location
- build directory
- build file cache directory

There's also name and path for each project. These aren't locations as such, but their default values are determined by locations, and there's no way to override their defaults.

Additionally, the locations for the build (or maybe the root project):
- root directory
- settings file location
- settings file cache directory
- inter-project build resolver directory
- ivy cache directory
- wrapper dist cache directory
- probably some other things like default imports file(s), plugin.properties, etc.

I'd like to be able to declare most of these locations in a file (or files) . Then I can do things like check them into source control and have the same layout on multiple machines, or share the same layout between several people. Even better if those files are scripts so that I can write code to declare my layout.

Overriding default locations from the command line is not really something I want to be able to do, but I guess it should be possible for most of the above locations.

The obvious place for most of these locations is in the settings file. Some don't really make sense there (eg settings cache dir). One option for these would be to add a gradle init script in gradle user home which can override pretty much anything.

The things that make sense to do through the settings file are:
- build resolver directory
- ivy cache directory
- for each project:
 - name
 - path (not for the root project)
 - project dir
 - build file
 - build dir

I'll leave it for another email to discuss how I think this might work, and how the command-line might work.


Adam

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

  http://xircles.codehaus.org/manage_email




Reply | Threaded
Open this post in threaded view
|

Re: arbitrary project layouts

hans_d
Administrator
In reply to this post by Adam Murdoch-2

On Aug 29, 2008, at 8:50 AM, Adam Murdoch wrote:

> Hi,
>
> I would like to start talking about 'arbitrary project layouts':  
> what that means, how we might solve the problem, and what can we do  
> to move towards the solution.
>
> To me, it means being able to control the location of any file or  
> directory that gradle uses to load stuff, cache stuff, and generate  
> stuff. It also means having reasonable defaults for all of these  
> things, so I don't need to care if I don't want to.
>
> Currently, the locations for each project are:
> - project directory
> - build file location
> - build directory
> - build file cache directory
>
> There's also name and path for each project. These aren't locations  
> as such, but their default values are determined by locations, and  
> there's no way to override their defaults.
>
> Additionally, the locations for the build (or maybe the root project):
> - root directory
> - settings file location
> - settings file cache directory
> - inter-project build resolver directory
> - ivy cache directory
> - wrapper dist cache directory
> - probably some other things like default imports file(s),  
> plugin.properties, etc.
>
> I'd like to be able to declare most of these locations in a file  
> (or files) . Then I can do things like check them into source  
> control and have the same layout on multiple machines, or share the  
> same layout between several people. Even better if those files are  
> scripts so that I can write code to declare my layout.
>
> Overriding default locations from the command line is not really  
> something I want to be able to do, but I guess it should be  
> possible for most of the above locations.
>
> The obvious place for most of these locations is in the settings  
> file. Some don't really make sense there (eg settings cache dir).  
> One option for these would be to add a gradle init script in gradle  
> user home which can override pretty much anything.
>
> The things that make sense to do through the settings file are:
> - build resolver directory
> - ivy cache directory
> - for each project:
>  - name
>  - path (not for the root project)
>  - project dir
>  - build file
>  - build dir

Cool.  It makes a lot of sense to me to put the project layout into  
this broad perspective. I haven't had this perspective before. This  
will make things consistent. I completely agree with the list of  
values which should be configurable.

A couple of thoughts:

-  I like script configuration files but they have one disadvantage  
to property or xml files: They are hard to modify by software. One  
example is release management where the release build logic  
increments the version properties in a properties file. That would be  
hard to do if we had only script configuration files. So I think we  
need both.

- Specifying the wrapper dist cache directory points to an  
interesting use case. First of all, if we want project specific  
settings for the wrapper, is not the build.gradle file a good place  
in this case, as the wrapper is a task (or maybe also a plugin the  
future)? That is the way we do it now. But if a user wants to define  
the wrapper properties for any Gradle project? It would be cool if it  
is possible to configure tasks/plugins in a user specific  
configuration file.

- I think we should have an additional settings.gradle in the user  
home. We have to think about how they best integrate with the  
respective gradle.properties files. In general I think user.home  
should have precedence over project root. And settings.gradle should  
have precedence over gradle.properties.

- One very cool thing we can do with our script configuration files  
is to let them register as listeners. That way they can do things  
before the build starts, after project initialization, clean up at  
the end, ...

- I think it makes a lot of sense to be able to specify the root dir  
location and the build file name via the command line. But probably  
we don't have to strive for completeness here. It might make sense to  
be able to set most of those values via system properties. Then we  
don't pollute the command line options with a bunch of obscure  
settings and yet we would be able to set them via the -D option. Just  
an idea.

- 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: arbitrary project layouts

dportello
In reply to this post by dportello
Maybe these layout scripts could be pluggable layout strategies which include an implementation of RootFinder and the methods's I've seen on AbstractProject which deal with file system and project navigation.



On Fri, Aug 29, 2008 at 7:58 AM, Dennis Portello <[hidden email]> wrote:
This sounds great, almost exactly what I was pondering. I think it might make also sense to have two sets of defaults, a hierarchical and flat layout which could be detected by Gradle. Looking through the source code yesterday I was contemplating how you could provide alternative layouts and have them picked-up automatically when invoking a build from any directory (sub-project).

Also, it might make sense to have a series of named layouts predefined in a gradle_home settings file/script which could be referenced from any project settings file, the two defaults being "flat" and "hirearchical".

-Dennis

On Fri, Aug 29, 2008 at 2:50 AM, Adam Murdoch <[hidden email]> wrote:
Hi,

I would like to start talking about 'arbitrary project layouts': what that means, how we might solve the problem, and what can we do to move towards the solution.

To me, it means being able to control the location of any file or directory that gradle uses to load stuff, cache stuff, and generate stuff. It also means having reasonable defaults for all of these things, so I don't need to care if I don't want to.

Currently, the locations for each project are:
- project directory
- build file location
- build directory
- build file cache directory

There's also name and path for each project. These aren't locations as such, but their default values are determined by locations, and there's no way to override their defaults.

Additionally, the locations for the build (or maybe the root project):
- root directory
- settings file location
- settings file cache directory
- inter-project build resolver directory
- ivy cache directory
- wrapper dist cache directory
- probably some other things like default imports file(s), plugin.properties, etc.

I'd like to be able to declare most of these locations in a file (or files) . Then I can do things like check them into source control and have the same layout on multiple machines, or share the same layout between several people. Even better if those files are scripts so that I can write code to declare my layout.

Overriding default locations from the command line is not really something I want to be able to do, but I guess it should be possible for most of the above locations.

The obvious place for most of these locations is in the settings file. Some don't really make sense there (eg settings cache dir). One option for these would be to add a gradle init script in gradle user home which can override pretty much anything.

The things that make sense to do through the settings file are:
- build resolver directory
- ivy cache directory
- for each project:
 - name
 - path (not for the root project)
 - project dir
 - build file
 - build dir

I'll leave it for another email to discuss how I think this might work, and how the command-line might work.


Adam

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

  http://xircles.codehaus.org/manage_email





Reply | Threaded
Open this post in threaded view
|

Re: arbitrary project layouts

dportello
In reply to this post by hans_d
sounds like an excellent idea

On Fri, Aug 29, 2008 at 8:25 AM, Hans Dockter <[hidden email]> wrote:

On Aug 29, 2008, at 8:50 AM, Adam Murdoch wrote:

Hi,

I would like to start talking about 'arbitrary project layouts': what that means, how we might solve the problem, and what can we do to move towards the solution.

To me, it means being able to control the location of any file or directory that gradle uses to load stuff, cache stuff, and generate stuff. It also means having reasonable defaults for all of these things, so I don't need to care if I don't want to.

Currently, the locations for each project are:
- project directory
- build file location
- build directory
- build file cache directory

There's also name and path for each project. These aren't locations as such, but their default values are determined by locations, and there's no way to override their defaults.

Additionally, the locations for the build (or maybe the root project):
- root directory
- settings file location
- settings file cache directory
- inter-project build resolver directory
- ivy cache directory
- wrapper dist cache directory
- probably some other things like default imports file(s), plugin.properties, etc.

I'd like to be able to declare most of these locations in a file (or files) . Then I can do things like check them into source control and have the same layout on multiple machines, or share the same layout between several people. Even better if those files are scripts so that I can write code to declare my layout.

Overriding default locations from the command line is not really something I want to be able to do, but I guess it should be possible for most of the above locations.

The obvious place for most of these locations is in the settings file. Some don't really make sense there (eg settings cache dir). One option for these would be to add a gradle init script in gradle user home which can override pretty much anything.

The things that make sense to do through the settings file are:
- build resolver directory
- ivy cache directory
- for each project:
 - name
 - path (not for the root project)
 - project dir
 - build file
 - build dir

Cool.  It makes a lot of sense to me to put the project layout into this broad perspective. I haven't had this perspective before. This will make things consistent. I completely agree with the list of values which should be configurable.

A couple of thoughts:

-  I like script configuration files but they have one disadvantage to property or xml files: They are hard to modify by software. One example is release management where the release build logic increments the version properties in a properties file. That would be hard to do if we had only script configuration files. So I think we need both.

- Specifying the wrapper dist cache directory points to an interesting use case. First of all, if we want project specific settings for the wrapper, is not the build.gradle file a good place in this case, as the wrapper is a task (or maybe also a plugin the future)? That is the way we do it now. But if a user wants to define the wrapper properties for any Gradle project? It would be cool if it is possible to configure tasks/plugins in a user specific configuration file.

- I think we should have an additional settings.gradle in the user home. We have to think about how they best integrate with the respective gradle.properties files. In general I think user.home should have precedence over project root. And settings.gradle should have precedence over gradle.properties.

- One very cool thing we can do with our script configuration files is to let them register as listeners. That way they can do things before the build starts, after project initialization, clean up at the end, ...

- I think it makes a lot of sense to be able to specify the root dir location and the build file name via the command line. But probably we don't have to strive for completeness here. It might make sense to be able to set most of those values via system properties. Then we don't pollute the command line options with a bunch of obscure settings and yet we would be able to set them via the -D option. Just an idea.

- 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: arbitrary project layouts

hans_d
Administrator
In reply to this post by dportello

On Aug 29, 2008, at 1:58 PM, Dennis Portello wrote:

> This sounds great, almost exactly what I was pondering. I think it  
> might make also sense to have two sets of defaults, a hierarchical  
> and flat layout which could be detected by Gradle.

I think it is a very good idea to specifically support flat layouts.  
I haven't thought about this. It should also be pretty easy to  
implement.

> Looking through the source code yesterday I was contemplating how  
> you could provide alternative layouts and have them picked-up  
> automatically when invoking a build from any directory (sub-project).

Either looking into each folder of the same hierarchy for a  
settings.gradle file. Or by naming convention (e.g. folder with the  
name 'master' in the same hierarchy).

>
>
> Also, it might make sense to have a series of named layouts  
> predefined in a gradle_home settings file/script which could be  
> referenced from any project settings file, the two defaults being  
> "flat" and "hirearchical".

I have to think about this.

- 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: arbitrary project layouts

Adam Murdoch-2
In reply to this post by dportello


Dennis Portello wrote:
> This sounds great, almost exactly what I was pondering. I think it
> might make also sense to have two sets of defaults, a hierarchical and
> flat layout which could be detected by Gradle.

I really like the idea of having layouts as first-class things that you
can define, with a few provided with gradle. I guess that a very small
number of layouts would cover the bulk of builds in practice.

How would you define 'hierarchical' and 'flat' layouts exactly? How do
you think the auto-detection would work?


Adam

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: arbitrary project layouts

Adam Murdoch-2
In reply to this post by hans_d
Hans Dockter wrote:
>
> -  I like script configuration files but they have one disadvantage to
> property or xml files: They are hard to modify by software. One
> example is release management where the release build logic increments
> the version properties in a properties file. That would be hard to do
> if we had only script configuration files. So I think we need both.
>

Good point. Configuration-as-code has become my new hammer since I
started using gradle: Every configuration problem needs a groovy-based
dsl as the solution :)

I think we could get by with something simple and consistent, such as an
optional properties file which lives in the same directory as the config
file and which declares the initial values for the properties of the
object being configured.

> - Specifying the wrapper dist cache directory points to an interesting
> use case. First of all, if we want project specific settings for the
> wrapper, is not the build.gradle file a good place in this case, as
> the wrapper is a task (or maybe also a plugin the future)? That is the
> way we do it now.

For that use case, yes, build.gradle is a good place for that.

I actually meant that I'd like to be able override the wrapper's
behaviour on a per-machine basis.  I'd like to declare somewhere that
any wrapper I run on my machine - regardless of which project it belongs
to or how it is configured - should cache the dists in, say,
~/gradle-dists instead of ~/.gradle/dist.

Generally, you could split the locations into 2 groups: those which
define the structure of the build (which projects, their names, build
files, etc), and those which are environmental (cache directories,
output directories, repositories).

The structural locations belong in a settings file, so that they are by
default the same everywhere the build is used. The environmental ones
could go there as well (mostly), but could also go in a gradle init
file, where they can be overridden. The wrapper cache dir would be an
environmental location.

>
> - I think we should have an additional settings.gradle in the user
> home. We have to think about how they best integrate with the
> respective gradle.properties files. In general I think user.home
> should have precedence over project root. And settings.gradle should
> have precedence over gradle.properties.
>

It feels like the thing in user home is not a settings file, but rather
something that can decorate a Settings object at the appropriate times.
I think the listener approach below is an excellent solution, where the
init script can decorate the Settings before and after it is evaluated,
and before and after the projects are evaluated.

This way, the question of precedence goes away - the init script can
choose either option.

> - One very cool thing we can do with our script configuration files is
> to let them register as listeners. That way they can do things before
> the build starts, after project initialization, clean up at the end, ...
>

Big +1 from me.

> - I think it makes a lot of sense to be able to specify the root dir
> location and the build file name via the command line. But probably we
> don't have to strive for completeness here. It might make sense to be
> able to set most of those values via system properties. Then we don't
> pollute the command line options with a bunch of obscure settings and
> yet we would be able to set them via the -D option. Just an idea.
>

Its a good idea, I think. One benefit of having a script init and
settings files is that one can code up whatever overrides they like
using system properties and/or custom configuration files.

What is the definition of the root directory in the arbitrary layout
world? Is it the project directory of the root project? Is it the
directory containing the settings.gradle? Is it just somewhere where we
start looking for well-named things in order to detect the layout? Do we
even need it?


Adam

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

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: arbitrary project layouts

hans_d
Administrator

>
> What is the definition of the root directory in the arbitrary  
> layout world? Is it the project directory of the root project? Is  
> it the directory containing the settings.gradle? Is it just  
> somewhere where we start looking for well-named things in order to  
> detect the layout? Do we even need it?
>

Good point. I have been pondering about this for quite a while. I see  
four purposes for what we currently call root project:

1.) The place where we have found the gradle.settings file.
2.) The dir of the gradle.settings file constitutes a config dir. Its  
location should be known to all projects as it might contain common  
stuff like lib folders, etc ....
3.) Contains code for configuring common things in the projects.
4.) Code for defining tasks that do something with the results of the  
subprojects.

Looking at the list above, do we need a project to model this? If it  
were only for 1-3, it might make sense not to use a project for this.  
But with 4.) in mind I think always having a root project makes  
sense, for any kind of layout.

- 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: arbitrary project layouts

hans_d
Administrator

On Sep 2, 2008, at 11:09 AM, Hans Dockter wrote:

>
>>
>> What is the definition of the root directory in the arbitrary  
>> layout world? Is it the project directory of the root project? Is  
>> it the directory containing the settings.gradle? Is it just  
>> somewhere where we start looking for well-named things in order to  
>> detect the layout? Do we even need it?
>>
>
> Good point. I have been pondering about this for quite a while. I  
> see four purposes for what we currently call root project:
>
> 1.) The place where we have found the gradle.settings file.
> 2.) The dir of the gradle.settings file constitutes a config dir.  
> Its location should be known to all projects as it might contain  
> common stuff like lib folders, etc ....
> 3.) Contains code for configuring common things in the projects.
> 4.) Code for defining tasks that do something with the results of  
> the subprojects.
>
> Looking at the list above, do we need a project to model this? If  
> it were only for 1-3, it might make sense not to use a project for  
> this. But with 4.) in mind I think always having a root project  
> makes sense, for any kind of layout.
>


To say it in other words. I think it makes sense that Gradle maps any  
kind of physical layout to a virtual hierarchical layout with a root  
project. In the case of a physical flat layout the master project is  
the root project and the other projects are its children.

- 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: arbitrary project layouts

dportello
I'm considering how I've handled multi-project builds in Eclipse (flat layout). I usually have a master(root) project which contains all the common build scripts and items included into the sub-project build scripts. I also write most of the reports into the master project.

On Tue, Sep 2, 2008 at 5:27 AM, Hans Dockter <[hidden email]> wrote:

On Sep 2, 2008, at 11:09 AM, Hans Dockter wrote:



What is the definition of the root directory in the arbitrary layout world? Is it the project directory of the root project? Is it the directory containing the settings.gradle? Is it just somewhere where we start looking for well-named things in order to detect the layout? Do we even need it?


Good point. I have been pondering about this for quite a while. I see four purposes for what we currently call root project:

1.) The place where we have found the gradle.settings file.
2.) The dir of the gradle.settings file constitutes a config dir. Its location should be known to all projects as it might contain common stuff like lib folders, etc ....
3.) Contains code for configuring common things in the projects.
4.) Code for defining tasks that do something with the results of the subprojects.

Looking at the list above, do we need a project to model this? If it were only for 1-3, it might make sense not to use a project for this. But with 4.) in mind I think always having a root project makes sense, for any kind of layout.



To say it in other words. I think it makes sense that Gradle maps any kind of physical layout to a virtual hierarchical layout with a root project. In the case of a physical flat layout the master project is the root project and the other projects are its children.


- 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: arbitrary project layouts

hans_d
Administrator
In reply to this post by hans_d

On Sep 2, 2008, at 11:09 AM, Hans Dockter wrote:

>
>>
>> What is the definition of the root directory in the arbitrary  
>> layout world? Is it the project directory of the root project? Is  
>> it the directory containing the settings.gradle? Is it just  
>> somewhere where we start looking for well-named things in order to  
>> detect the layout? Do we even need it?
>>
>
> Good point. I have been pondering about this for quite a while. I  
> see four purposes for what we currently call root project:
>
> 1.) The place where we have found the gradle.settings file.

The place where we find the gradle.settings file does not need to be  
the same as the dir of the root project (though often it is). But we  
will make this configurable. This does not change my overall argument  
for the case of a root project.

> 2.) The dir of the gradle.settings file constitutes a config dir.  
> Its location should be known to all projects as it might contain  
> common stuff like lib folders, etc ....
> 3.) Contains code for configuring common things in the projects.
> 4.) Code for defining tasks that do something with the results of  
> the subprojects.
>
> Looking at the list above, do we need a project to model this? If  
> it were only for 1-3, it might make sense not to use a project for  
> this. But with 4.) in mind I think always having a root project  
> makes sense, for any kind of layout.
>

- 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: arbitrary project layouts

dportello
Hans,

I'd be very pleased if I could get multi-project builds working Eclipse without work-arounds. Whatever path takes us there, I'm willing to follow.

Speaking of Eclipse, I took my fee development time this week and applied it to writing a builder which executes groovy scripts (tighter integration of groovy into the eclipse build process). In the course of writing this plugin, I've picked apart the ANT integration plugins and hope to start working on something similar for Gradle in the near future.

-Dennis

On Wed, Sep 3, 2008 at 3:49 AM, Hans Dockter <[hidden email]> wrote:

On Sep 2, 2008, at 11:09 AM, Hans Dockter wrote:



What is the definition of the root directory in the arbitrary layout world? Is it the project directory of the root project? Is it the directory containing the settings.gradle? Is it just somewhere where we start looking for well-named things in order to detect the layout? Do we even need it?


Good point. I have been pondering about this for quite a while. I see four purposes for what we currently call root project:

1.) The place where we have found the gradle.settings file.

The place where we find the gradle.settings file does not need to be the same as the dir of the root project (though often it is). But we will make this configurable. This does not change my overall argument for the case of a root project.


2.) The dir of the gradle.settings file constitutes a config dir. Its location should be known to all projects as it might contain common stuff like lib folders, etc ....
3.) Contains code for configuring common things in the projects.
4.) Code for defining tasks that do something with the results of the subprojects.

Looking at the list above, do we need a project to model this? If it were only for 1-3, it might make sense not to use a project for this. But with 4.) in mind I think always having a root project makes sense, for any kind of layout.


- 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: arbitrary project layouts

hans_d
Administrator
Hi Dennis,

On Sep 3, 2008, at 2:45 PM, Dennis Portello wrote:

> Hans,
>
> I'd be very pleased if I could get multi-project builds working  
> Eclipse without work-arounds. Whatever path takes us there, I'm  
> willing to follow.

I have started to implement. I'm optimistic that Gradle provides this  
feature sometimes tomorrow.

>
>
> Speaking of Eclipse, I took my fee development time this week and  
> applied it to writing a builder which executes groovy scripts  
> (tighter integration of groovy into the eclipse build process). In  
> the course of writing this plugin, I've picked apart the ANT  
> integration plugins and hope to start working on something similar  
> for Gradle in the near future.

Cool.

- 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: arbitrary project layouts

dportello
great news! thank you

-Dennis

On Wed, Sep 3, 2008 at 10:13 AM, Hans Dockter <[hidden email]> wrote:
Hi Dennis,


On Sep 3, 2008, at 2:45 PM, Dennis Portello wrote:

Hans,

I'd be very pleased if I could get multi-project builds working Eclipse without work-arounds. Whatever path takes us there, I'm willing to follow.

I have started to implement. I'm optimistic that Gradle provides this feature sometimes tomorrow.




Speaking of Eclipse, I took my fee development time this week and applied it to writing a builder which executes groovy scripts (tighter integration of groovy into the eclipse build process). In the course of writing this plugin, I've picked apart the ANT integration plugins and hope to start working on something similar for Gradle in the near future.

Cool.


- Hans

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





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

  http://xircles.codehaus.org/manage_email