Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Rename FileMetadata{Snapshot -> }

Snapshot doesn't add anything to the name.

  1. … 50 more files in changeset.
Replace FileMetadata by FileMetadataSnapshot

  1. … 16 more files in changeset.
Improve formatting in OuputFilterUtil

Fixes.

  1. … 23 more files in changeset.
Fixes.

  1. … 23 more files in changeset.
Fixes.

  1. … 23 more files in changeset.
Fixes.

  1. … 23 more files in changeset.
Fixes.

  1. … 23 more files in changeset.
Introduce internal `@EventScope` annotation to attach to listener interfaces to declare which scope their events are generated in.

Add some validation to `ListenerManager` to verify that each listener interface is annotated with the correct scope.

  1. … 62 more files in changeset.
Introduce internal `@EventScope` annotation to attach to listener interfaces to declare which scope their events are generated in.

Add some validation to `ListenerManager` to verify that each listener interface is annotated with the correct scope.

  1. … 62 more files in changeset.
Introduce internal `@EventScope` annotation to attach to listener interfaces to declare which scope their events are generated in.

Add some validation to `ListenerManager` to verify that each listener interface is annotated with the correct scope.

  1. … 62 more files in changeset.
Introduce internal `@EventScope` annotation to attach to listener interfaces to declare which scope their events are generated in.

Add some validation to `ListenerManager` to verify that each listener interface is annotated with the correct scope.

  1. … 62 more files in changeset.
Introduce internal `@EventScope` annotation to attach to listener interfaces to declare which scope their events are generated in.

Add some validation to `ListenerManager` to verify that each listener interface is annotated with the correct scope.

  1. … 62 more files in changeset.
Introduce internal `@EventScope` annotation to attach to listener interfaces to declare which scope their events are generated in.

Add some validation to `ListenerManager` to verify that each listener interface is annotated with the correct scope.

  1. … 62 more files in changeset.
Introduce internal `@EventScope` annotation to attach to listener interfaces to declare which scope their events are generated in.

Add some validation to `ListenerManager` to verify that each listener interface is annotated with the correct scope.

  1. … 62 more files in changeset.
Update access type for non-trees

aka outside of `DirectorySnapshotter` and

`FileSystemSnapshotBuilder`

  1. … 5 more files in changeset.
Update access type for non-trees

aka outside of `DirectorySnapshotter` and

`FileSystemSnapshotBuilder`

  1. … 5 more files in changeset.
Update access type for non-trees

aka outside of `DirectorySnapshotter` and

`FileSystemSnapshotBuilder`

  1. … 5 more files in changeset.
Some Java 8 polishing in OutputFilterUtil

Some Java 8 polishing in OutputFilterUtil

Introduce access type on FileSystemLocationSnapshot

but don't fill it, yet.

  1. … 23 more files in changeset.
Introduce access type on FileSystemLocationSnapshot

but don't fill it, yet.

  1. … 23 more files in changeset.
Introduce access type on FileSystemLocationSnapshot

but don't fill it, yet.

  1. … 23 more files in changeset.
Fix memory leak in component metadata rule executor

The cross-build cache for cached component metadata rules stores

instances of realized Maven/Ivy module metadata in memory. The

problem is that those instances shouldn't have any state from

the project/Gradle build attached to them (they should be good

old POJOs) but for implementation reasons, they are not. In

particular, they keep a reference to the attributes factory,

which in turn keeps a reference to the object factory, which,

itself, will leak classloaders.

As a consequence, as more builds get executed, it was _possible_

that the cache would release some entries, but for the classloaders

to be released, it would require _all_ the entries from the same

build to be released from the cache. It turns out this event is

unlikely and as a consequence, builds end up running out of

memory.

This commit fixes the problem by making sure that at the end of

a build, we clear the in-memory cache of component metadata rules.

Therefore, cross-build, we would still read the result of the

execution of rules from the binary, on disk cache, but we would

not reuse in-memory results from previous builds.

This fix has been tested and validated by a user facing this

issue. Memory usage dropped from 11GB of memory to 1GB.

  1. … 20 more files in changeset.
Fix memory leak in component metadata rule executor

The cross-build cache for cached component metadata rules stores

instances of realized Maven/Ivy module metadata in memory. The

problem is that those instances shouldn't have any state from

the project/Gradle build attached to them (they should be good

old POJOs) but for implementation reasons, they are not. In

particular, they keep a reference to the attributes factory,

which in turn keeps a reference to the object factory, which,

itself, will leak classloaders.

As a consequence, as more builds get executed, it was _possible_

that the cache would release some entries, but for the classloaders

to be released, it would require _all_ the entries from the same

build to be released from the cache. It turns out this event is

unlikely and as a consequence, builds end up running out of

memory.

This commit fixes the problem by making sure that at the end of

a build, we clear the in-memory cache of component metadata rules.

Therefore, cross-build, we would still read the result of the

execution of rules from the binary, on disk cache, but we would

not reuse in-memory results from previous builds.

This fix has been tested and validated by a user facing this

issue. Memory usage dropped from 11GB of memory to 1GB.

  1. … 20 more files in changeset.
Fix memory leak in component metadata rule executor

The cross-build cache for cached component metadata rules stores

instances of realized Maven/Ivy module metadata in memory. The

problem is that those instances shouldn't have any state from

the project/Gradle build attached to them (they should be good

old POJOs) but for implementation reasons, they are not. In

particular, they keep a reference to the attributes factory,

which in turn keeps a reference to the object factory, which,

itself, will leak classloaders.

As a consequence, as more builds get executed, it was _possible_

that the cache would release some entries, but for the classloaders

to be released, it would require _all_ the entries from the same

build to be released from the cache. It turns out this event is

unlikely and as a consequence, builds end up running out of

memory.

This commit fixes the problem by making sure that at the end of

a build, we clear the in-memory cache of component metadata rules.

Therefore, cross-build, we would still read the result of the

execution of rules from the binary, on disk cache, but we would

not reuse in-memory results from previous builds.

This fix has been tested and validated by a user facing this

issue. Memory usage dropped from 11GB of memory to 1GB.

  1. … 22 more files in changeset.
Spike invalidating in-memory cache at the end of a build

  1. … 22 more files in changeset.
Spike invalidating in-memory cache at the end of a build

  1. … 21 more files in changeset.
Fixes for test coverage.

  1. … 6 more files in changeset.
Add more test coverage for using CopySpec with instant execution.

Reduce the verbosity of some instant execution logging.

  1. … 16 more files in changeset.