sounds like an excellent idea On Fri, Aug 29, 2008 at 8:25 AM, Hans Dockter <[EMAIL PROTECTED]> 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 > > >
