I have gotten init scripts working. The code can be seen on GitHub at
git://github.com/sappling/gradle.git in branch init_script. This allows
init scripts to be found in the user's home dir (looks for file
~/.gradle/init.gradle) and supports a --init-script <filepath> option. The
init script is then executed before the build is started. I have this
sample script:
initscript {
repositories { mavenCentral() }
dependencies { classpath 'org.apache.commons:commons-math:2.0' }
}
// We want to test if commons-math was properly added to the init script
classpath
def lhs = new org.apache.commons.math.fraction.Fraction(1, 3);
println 'fraction is '+lhs
Which prints out "fraction is 1/3" almost immediately. I still need to
fix/add some tests and documentation, but the basic funtionality is
working. I'm very pleased that I got this much done so quickly, but I have
some concerns.
1. The .gradle compiled caches are stored whereever the scripts are
found. Is this desirable? For example, the ~/.gradle/init.gradle results
in a ~/.gradle/.gradle/cache directory structure for the script. Similarly,
if I use --init-script /temp/init.gradle I end up with a /temp/.gradle/cache
directory structure. Should we put these somewhere else?
2. The "buildscript" implementation put methods on Project called
buildscript() and getBuildscript(), and now I've put methods on Build called
initscript() and getInitscript(). This seems a little confusing.
3. I wanted to reuse the buildscript support from Project as much as
possible. This required the use of a ScriptHandler, which is currently made
by the ProjectServiceRegisteryFactory. For now, I added a factory method
that takes a build instead of a project. The name of the class can be
changed, but I wasn't sure this approach was in line with the intent for
this class.
4. My implementation of DefaultProjectServiceRegisteryFactory needs to
create several objects that seem project centric (makes sense, but I have a
build object, not a project). Some of my implementations are silly, but are
working in simple tests. Does something need to change here, or can we keep
the silly implementations until other changes make the issue easier to deal
with?
5. I need to unify the ScriptClassLoaderProvider used by the initscript
support with the buildSrc module class loader. I think that will finally
make me happy with the buildSrc class loader stuff, but I'm not sure how to
unify them.
I think these are my main concerns. Any ideas? :)
--
John Murph
Automated Logic Research Team
