Hans Dockter wrote:
In Gradle we have the necessity that some information is provided
_before_ the build script is compiled (for example if you want to add
additional jars to the build script classpath). At the moment we solve
this with a settings.gradle file. Tom and I have talked about this
during Devoxx. We both would love to get rid of this additional build
file 'settings.gradle'.
I would love to see it go as well.
What we would like to do instead, is to have a two phase processing of
the build.gradle file. The first parsing would extract information for
example about the build script classpath or about project naming. The
second step would be the actual compile.
I'm not sure about this approach. The build file stops being a groovy
script and turns into something else, where some bits of the code are
executed differently to other bits (or not executed at all). This
doesn't feel right to me. Can you describe how this would work?
I think there might be some alternative approaches which don't require
execution magic. Currently, we use the settings file for a few different
use cases. We don't need to solve each the same way, and we can
potentially move some of the more common use cases to the build file,
and leave the settings file for more exotic usages.
Here's what we use the settings file for, with some potential options
for replacement:
1. Locating the root project.
Currently, we scan up the directory hierarchy from the current directory
looking for a settings file.
A simple option here is to scan up the hierarchy for .gradle files, and
use the file from the highest location we find.
2. Naming the root project.
Currently, the only way to give the root project a name other than the
default is via the settings file.
As discussed in another email, one option is to use the build file's
name as the default project name.
Another option is to allow the project name to be specified in the build
file. I think there could be a window early in the execution of the
build file where the name can be changed. One possibility is to allow
the name to be changed only before any other modification is made to the
project.
3. Defining subprojects.
Currently, the only way to add projects to a build is via the settings file.
One option is to allow subprojects to be added to a project, pretty much
the same way we allow tasks to be added to the project. Or
configurations added to the dependency manager.
4. Making external plugins available for use.
Currently, you can use an external plugin by adding it as a dependency
in the settings file.
Some options:
- Allow the build file a way to add stuff to its classloader
- Use a special configuration which defines the classpath for loading
plugins
- Allow dependencies to be specified when calling usePlugin()
- Add a definePlugin() method, which would take a bunch of dependencies,
the plugin classname, and the desired plugin name. These definitions
would be inherited by subprojects.
5. Making classes available for use in the build file.
Interestingly, we have 2 places where you can declare extra classes you
want to make available to the build file: in the settings file, and in
the runtime configuration for the buildSrc project.
Perhaps we could just use buildSrc as the replacement for this use case.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
