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
