John Murph wrote:
I have gotten init scripts working. The code can be seen on GitHub at
git://github.com/sappling/gradle.git
<http://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.
The code looks good.
There is a bit of duplication in there, which I think we should merge
for build scripts, init scripts, and settings scripts. But that can wait
for another pass, after this change is merged.
As always, I think an integration test would be good. It should include
a sad-day case where the init script blows up, to make sure we have
error reporting wired-up ok.
I think we can leave all the following issues until after this change is
merged:
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?
I think this is a separate issue. Right now, Gradle caches the compiled
script in the same directory as the script, so I think we should keep
doing this for now. Once we've merged the infrastructure a bit, then it
might be a better time to address this.
There's already a JIRA issue for this problem:
http://jira.codehaus.org/browse/GRADLE-428
Personally, I'd rather all this stuff ended up in 1 place (maybe in
~/.gradle, maybe in the build's root dir).
1. 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.
Indeed, given that there are potentially multiple init scripts. I think
this belongs on an InitScript object. And Project.buildscript() and
getBuildscript() probably belong on ProjectScript. This would also allow
multiple build scripts per project.
1. 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.
I guess we generalise it to be a ServiceRegistryFactory, with a couple
of implementations.
1. 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?
This class needs busting up, so that we can reuse bits of it for the
init scripts.
1. 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.
For this, we should change BuildSrcBuilder to implement
ScriptClassLoaderProvider, so that we have a single concept for
ClassLoader management. Then, we can use a chaining
ScriptClassLoaderProvider to wire the various pieces together.
I would add, also:
1. We will need something in the userguide. This feels like a new chapter.
Adam
