[GRADLE-588] Add support for an init script Created: 10/Aug/09  Updated: 04/Jan/13  Resolved: 26/Sep/09

Status: Resolved
Project: Gradle
Affects Version/s: None
Fix Version/s: 0.8

Type: New Feature
Reporter: John Murph Assignee: Adam Murdoch
Resolution: Fixed Votes: 0

Issue Links:
Supercedes
Supercedes GRADLE-29 Introduce optional gradle_before and ... Resolved

 Description   

It is desirable for Gradle to support the concept of initialization scripts. These scripts could set up the environment for each Gradle execution. Several use cases have been discussed:

  • Integration with a tool (IDE or CI server). Such a tool might wish to specify an init script to register custom listeners to Gradle's build.
  • Information about the user, such as repository/app server/database authentication information.
  • Personal customisations, such as custom task aliases, logging configuration, additional plugins to apply.
  • Information about the environment, such as where JDKs are installed, dependency cache configuration, overrides to repository configuration.

The first of these needs the script to be explicitly stated via command line options. I envision a "--init-script" option that must be followed by a file path. For ALL such options on the command line, the specified script would be executed. The remaining use cases are per-user settings that would benefit from an automatically included "user init script" that does not have to be explicitly stated on the command line for every execution of Gradle. I envision looking in ~/.gradle/init.gradle for such a script. If one is found, it is also executed.

These scripts need to be able to specify classpaths and load classes from those classpaths. This is similar to the buildscript idea currently supported in build.gradle scripts. Init scripts will have a similar mechanism. They also need to be able to register listeners with Gradle. To accomplish this, the init scripts will be executed with the Build object as their "delegate". This means that init scripts would configure builds, and build scripts would configure projects. That's a bit confusing, but can be worked out later.

 Comments   
Comment by John Murph [ 10/Aug/09 ]

I have the first Phase 1 implementation up on GitHub at git://github.com/sappling/gradle.git in branch init_script.

Comment by Adam Murdoch [ 11/Aug/09 ]

This looks good to me. Some comments:

  • The return type of Gradle.getBuild() should be Build, rather than BuildInternal
  • I think we should keep Gradle.addBuildListener(). It would delegate to Build.addBuildListener()
  • We could replace the fire*() methods on BuildInternal with a single getBuildListenerBroadcaster(), like we do for ProjectEvaluationListener.
  • Should we change the parameter of BuildListener.buildStarted() from StartParameter to Build?
Comment by John Murph [ 11/Aug/09 ]
  • The return type of Gradle.getBuild() should be Build, rather than BuildInternal

I was thinking of this method as an implementation detail, so I uesd BuildInternal. Will this method ever be exposed to users? I don't know of any way for them to get the Gradle instance right now. However, I don't really mind making it Build either. Unless you override yourself, I'll change it to Build.

  • I think we should keep Gradle.addBuildListener(). It would delegate to Build.addBuildListener()

Why? Once again, this seems like an unnecessary method. Right now several uses do "gradle.getBuild().addBuildListener()" but I expect that to change. Again, not very important to me, so I'll add it back unless you override yourself.

  • We could replace the fire*() methods on BuildInternal with a single getBuildListenerBroadcaster(), like we do for ProjectEvaluationListener.

I thought about doing that several times during this work. Ultimately I decided not yet just to keep the change smaller. I will do it now.

  • Should we change the parameter of BuildListener.buildStarted() from StartParameter to Build?

Oops. I had thought I did that. Must have missed it. Thanks for the reminder.

Comment by John Murph [ 11/Aug/09 ]

I just pushed updated code to the init_script branch on GitHub. This incorporates all suggestions (except for Gradle.getBuild(), I removed that method as it was no longer used after adding the Gradle.adBuildListener() method back). I also updated it to work with the "build buildSource before settings" change that got submitted. I think this completes phase 1.

For phase 2, I intent to add basic init script support (--init-script command line and per-user file handling). This includes allowing the classpath to be specified and used in the script. The "delegate" object will be Build, but I will not add much to Build to support other needs. Seems fairly straight forward to me. Sound good?

Comment by Adam Murdoch [ 26/Sep/09 ]

This is all finished. Thank you for the patches.

Generated at Wed Jun 30 11:33:46 CDT 2021 using Jira 8.4.2#804003-sha1:d21414fc212e3af190e92c2d2ac41299b89402cf.