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
