Fredrik Ekholdt freekh

This is a different take on the open questions set out by Adam, but it is maybe a bit too different to what we have already set out to do so I wanted to keep it separate. Maybe there are some ideas here that can be incorporated as we move along.

Intro

The general idea is to use an execution engine that computes which and how to run user specified actions/tasks based which properties a user have set and the task that is invocated (by the user).

Tasks and properties have dependencies to other tasks and properties and it is whether these dependencies have been set and to what that defines whether or how a task should be run. For the execution engine, really only 3 concepts exists: tasks, properties and scopes (see definitions below). An important attribute of properties and tasks is that they are lazy (see later). For convience there are a couple of more concepts which are all built on top of these concepts: component, platform and plugin. Extending such a build system, would mean to define the things tha

NOTE: This document was written the 16th September 2014 and are based on notes taken before that - it might be wrong, outdated or misleading.

The new configuration model introduces the concepts of rules and models. A rule may add or mutate the model, which defines data which a user can define. Rules, models and tasks all live in plugins. The model is loaded eagerly when the the plugin is applied to a project, while the rules are lazily (when needed) evaluated.

Rules

In practice, rules are annotations on methods and there are currently 3 types: immutable (@Model), mutable (@Mutate) and finalized (@Finalize). The parameters of the method (subjects) are the dependencies. For mutable rules, the first parameter indicates that it is the mutating subject (the object which we will mutate/change), while the rest are the dependencies of the rule. An immutable rule may produce the types used by other rules. An example of this is if an immutable 'rule1' maps a model to another type, a mutable (or immutable) 'rul

Platform variance: The concept of variance is one of the key features on our roadmap (http://www.gradle.org/roadmap#variant). The highlevel goal is to find a flexible and safe way for users to describe what they want their build to do. From this we can infer what needs to be done to get there.

There are a bunch of considerations to take:

we need an easy way to define new platforms. Examples: Scala, Android, Play, ....
we need to specialize platforms: Scala is a Jvm platform with some additional properties, Android is a combination of Jvm and C (NDK) and some additional properties, Gradle is just Groovy with some extra APIs, ...
we need an easy way to verify determine whether a platform can be created.

Keybase proof

I hereby claim:

I am freekh on github.
I am freekh (https://keybase.io/freekh) on keybase.
I have a public key whose fingerprint is 22C9 04FB 3DF6 09FB 8221 D3D1 AB18 07A8 44F1 2F8D

To claim this, I am signing this object:

	main = asm.Executable

	main { //could also not name the exec and use asm.Executable { ....?
	x86.architecture = "i386" //x86 is a platform

	binaries.all {
	if (toolChain in VisualCop) {
	source sources.i386_masm.asm
	assembler.args "/Zi"
	} else {

	package adept.gradle

	import adept.artifact.models.{ArtifactAttribute, ArtifactHash}
	import adept.hash.Hasher
	import adept.resolution.models._
	import org.scalatest.{FunSuite, Matchers}
	import _root_.java.io.File


	//DSL helpers