Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Groovy incremental compilation support

  1. … 45 more files in changeset.
Groovy incremental compilation support

  1. … 45 more files in changeset.
Groovy incremental compilation support

Signed-off-by: Bo Zhang <bo@gradle.com>

  1. … 45 more files in changeset.
Daily commit

  1. … 33 more files in changeset.
Groovy incremental compilation support

  1. … 21 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 902 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 902 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 890 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 897 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 902 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 902 more files in changeset.
Add support for incremental compilation of Groovy sources

This **experimental** feature works similarly to Java's, and actually

reuses most of the Java infrastructure. It should be cleaned up and

replace annotation processor detection with AST xforms detection.

  1. … 17 more files in changeset.
Simplify worker daemon classloader hierarchy

  1. … 18 more files in changeset.
Simplify worker daemon classloader hierarchy

  1. … 18 more files in changeset.
Simplify worker daemon classloader hierarchy

  1. … 18 more files in changeset.
Simplify worker daemon classloader hierarchy

  1. … 18 more files in changeset.
Simplify worker daemon classloader hierarchy

  1. … 18 more files in changeset.
Simplify worker daemon classloader hierarchy

  1. … 16 more files in changeset.
Simplify worker daemon classloader hierarchy

  1. … 19 more files in changeset.
Pass compiler classes and instantiate them in the worker

  1. … 25 more files in changeset.
Pass compiler classes and instantiate them in the worker

  1. … 24 more files in changeset.
Pass compiler classes and instantiate them in the worker

  1. … 25 more files in changeset.
Fix a bunch of tests and do some cleanup

  1. … 35 more files in changeset.
Fix non-classdir tests

  1. … 3 more files in changeset.
Handle removals of classes transitively

After further cleaning up our class change detection logic,

I noticed that we were handling additions and removals very

differently. This has been corrected and we now detect transitive

removals too. This doesn't happen often in practice, as one needs

to deliberately exclude a task to trigger the bug that was fixed.

Nevertheless, it's good to have symmetric logic.

  1. … 6 more files in changeset.
Detect changes to transitive dependencies on incremental compilation

The incremental compiler was completely ignoring changes in transitive

dependencies, except for changes to supertypes, which seems like a really

weird decision. It has been fixed to instead take all possible transitive

references into account. As a result the code is also simpler.

  1. … 8 more files in changeset.
Remove synchronization around all system property getters

  1. … 5 more files in changeset.
Support resource creation in incremental annotation processors

Allow resources to be created by incremental annotation processors using

`Filer#createResource`. Allow resources to be created in the three currently

existing output locations on `StandardLocation`: `SOURCE_OUTPUT`,

`CLASS_OUTPUT`, and `NATIVE_HEADER_OUTPUT`.

A generated resource is uniquely identified by its `Location` and its path

relative to that `Location`. A new type `GeneratedResource` is created to that

effect. Data of that type is then plumbed through the existing annotation

processing infrastructure, ultimately reaching

`IncrementalCompilationInitializer` so that cleaning may be done.

Resolves #4702.

Signed-off-by: Ian Kerins <ianskerins@gmail.com>

  1. … 32 more files in changeset.
Use notimestamp for JavaDoc and noversionstamp for GroovyDoc

Timestamps in the generated documentation have very limited practical use,

however they mark all the files as "modified" even in case of a small changes.

Having notimestamp by default enables repeatable documentation build, and

it simplifies storage of the documentation (e.g. reduces git traffic, etc)

Signed-off-by: Vladimir Sitnikov <sitnikov.vladimir@gmail.com>

  1. … 2 more files in changeset.
Introduce an internal factory to create `JavaForkOptions`, to encapsulate the service(s) needed to create instances of this type and decouple clients from this detail. This could/should move to `ObjectFactory` or some other public factory type.

  1. … 42 more files in changeset.