Adam Murdoch wrote:
Steve Appling wrote:
I have been investigating build tools for a very large project
(~44,000 files and >50 modules) and have been very impressed with
Gradle so far. The potential flexibility of the system provides a
great opportunity to help us manage the complexity of our build.
I want to be able to extend the DSL syntax of Gradle for use in our
build system without complicating the core of Gradle. For instance,
we currently build multiple products from an overlapping set of
modules. We can't use a single settings.gradle file to specify all
products, but want to use our own DSL format to specify the various
modules that make up each product.
I've also wanted to do something similar, where I want to execute a
bunch of code in the settings file to add dynamic stuff to the Settings
object and Project objects. I didn't want the code in the settings file,
because I wanted to reuse it across a bunch of builds. I ended up
solving it with some copy-and-paste coding.
We have solved this problem (to some degree) for build files - you add
your code to the buildSrc project or to an external project which you
drag in via the classpath specified in the settings file, and then use a
plugin (or whatever) to execute the code. I think the best solution is
to generalise this approach, so that it will work for pretty much any
type of script that Gradle executes (build files, settings files, user
config files, ...).
One change that we've discussed in the past is to move the declaration
of the build file classpath from the settings file to the build file
itself. We could use this approach for pretty much any script, including
the settings file. Part of this change would also be to generalise the
buildSrc concept, to make it possible to declare one or more other
projects to be included in the classpath of the script.
I think this would solve your problem nicely.
I made an initial implementation of this, but ran into some issues. I
wanted to add new methods to the Project interface as well as
introduce some new interfaces of my own that could be used in my
build.gradle files. I can add some of this functionality in
settings.gradle using expando methods, but only if my new features are
all defined in settings.gradle. I would prefer to put them in the
buildSrc special project, but it is not available when settings.gradle
is executed. If I wait to inject these features in my main
build.gradle, it is too late because the projects have already been
instantiated.
I would like gradle to support a new script (perhaps extend.gradle) in
the buildSrc module that would be run with the classloader that will
be used for all the build.gradles. This needs to be executed before
all the build.gradles so that all the extensions can already be in place.
You could instead put this code in a plugin implementation in your
buildSrc project, and then use that plugin from the root project. Then
we don't need this new concept.
I'm not sure how this would address the issue of extending the Project
itself (or to build up the tree of projects in a different manner). By
the time the root project's build.gradle is called, the project tree has
already been built. I think I need to be able to add my extensions
before this.
Let me state the problem more clearly:
During the evaluation of settings.gradle, I can extend the Project
interface or change the set of projects that will be built, but I can't
use utility classes from under buildSrc or reference classes defined
there from inside a build.gradle.
If I try to use a plugin or direct code from inside a build.gradle, it
is too late - the project tree has already been built.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
