Gradle 2.4's daemon class reuse and statics

Help/Discuss
1

Hi,

I have an issue with Gradle 2.4’s daemon class reuse and it’s inability to handle statics, and I’m looking for ideas on how to resolve it.

We have a custom version class that generates extra parts of our version numbers, but it needs to only be generated once per build. For example, a timestamp cannot change throughout the lifecycle of the build or across subprojects. To implement this we generated and stored that data statically. This of course breaks with the new class reuse.

My immediate thoughts were to initialize and store the required data in a property of the root project. If the property already exists then it can just be read, making it behave like the previously static data. However, this version class has no reference to the project it is being applied to and therefore I don’t have a way of getting a reference to the root project. I’d really like to try and avoid changing the constructor because doing so would mean that I have a lot of projects that need to be updated.

I.E. using our version class looks something like:

version = new Version( 1, 2, 3 )

and I’d like to avoid the following if possible:

version = new Version( project, 1, 2, 3 )

Unfortunately I cannot just generate and store the data in non-static members of the Version objects since a multi-project build could contain sub projects with different Version instances. That could result in differently generated data which really should be the same (a timestamp should be the same across all subprojects but would differ based on the timing of each subproject’s configuration).

Does anyone know of a way I can get a reference to the root project without changing the constructor of our version class in order to pass in a project reference?
Any other ideas?

Thanks, Chris

2

To get build scoped data, you can attach it to the root project. The root project is not available statically, but you could do this yourself (i.e. and reset it each build). Your version class could then use this static access. It’s messy, but the only thing I can think of shy of changing your constructor.

3

Was the idea of allowing some control over the class reuse ever considered?

Is it feasible to have a feature where a class could be annotated such that it won’t be optimized with class reuse?

4

We decided to proceed with a constructor change to include the project.

Thanks for the input @luke_daley.