Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Publish 5.6.1-20190902230020+0000

Persist only file tree roots contained in file collections

in the instant execution cache. Before this change, all the files

in the file tree have been persisted instead of the root only.

Improve outgoing variant report

* Add capabilities information to the report

Improve outgoing variant report

* Add capabilities information to the report

Improve outgoing variant report

* Add capabilities information to the report

Merge branch 'master' into lptr/deprecations/defaulttask

Deincubate API elements defined in Gradle 5.4 and before in the 'ide' and 'tooling-api' subprojects (#10406)

- De-incubate API elements defined in Gradle 5.4 and before in the 'ide' and 'tooling-api' subprojects

- Mention API promotion in release notes

    • -0
    • +1
    /subprojects/docs/src/docs/release/notes.md
  1. … 42 more files in changeset.
Mention API promotion in release notes

    • -0
    • +1
    /subprojects/docs/src/docs/release/notes.md
Only keep artifacts from pom if the file path is unambiguous

If the packaging indicated in a pom is not in the list of 'known

jar packagings', we assume that the artifact could have the extension

indicated by the packaging. We first test if that artifact exists

with a HEAD request, and only if it does not, we go for the 'jar'

artifact.

Since using a variant file rule disables this mechanism, we remove

such ambiguous artifacts from the modified artifact list to give users

the chance to explicitly state which artifact to expect in the rule

they add anyway.

Only keep artifacts from pom if the file path is unambiguous

If the packaging indicated in a pom is not in the list of 'known

jar packagings', we assume that the artifact could have the extension

indicated by the packaging. We first test if that artifact exists

with a HEAD request, and only if it does not, we go for the 'jar'

artifact.

Since using a variant file rule disables this mechanism, we remove

such ambiguous artifacts from the modified artifact list to give users

the chance to explicitly state which artifact to expect in the rule

they add anyway.

Improvements in core dependency management chapter

Improvements in core dependency management chapter

Improvements in core dependency management chapter

Document variant reporting task

- Includes clarified documentation on usage of classes for java-library

projects.

Document variant reporting task

- Includes clarified documentation on usage of classes for java-library

projects.

Document variant reporting task

- Includes clarified documentation on usage of classes for java-library

projects.

Restore child projects loader scope inheriting from the root project

Remove unnecessary parameter

Merge remote-tracking branch 'origin/master' into ldaley/settings-before-buildsrc

Merge branch 'master' into wolfs/java-compile-input-changes

Merge branch 'master' into wolfs/java-compile-input-changes

Improve incremental compilation for Java

This patch splits the collected dependencies found in a .class file into "accessible" and "private" dependencies.

* "Accessbile" dependencies are classes that belong to non-private fields, non-private method signatures, class signature ("extends", "implements") etc

* "Private" dependencies are classes that belong to private fields, private methods and classes used in method bodies (i.e. just in "the code")

The TL;DR of the approach is to change the algorithm in `ClassSetAnalysis.getRelevantDependents` to only recurse for "accessible" dependencies.

Goal by example:

Consider classes like

```

class A {

private B b

}

class B {

private C c

}

class C {

}

```

The previous algorithm in `ClassSetAnalysis.getRelevantDependents` would recompile all classes, if `C` was changed. The new algorithm recompiles

just `B` and `C`, because `C` has been changed and `B` uses `C`. But it doesn't recompile `A`, because `A` is not affected by the change. The same

is true, if `C` would have been only used in a method body of `B` or in the signature of a `private` function in `B`.

The algorithm properly handles changes to classes used in the following example:

```

public class SomeClass {

List<Integer> field = new LinkedList<Integer>();

private AccessedFromPrivateField accessedFromPrivateField;

AccessedFromPackagePrivateField someField;

private AccessedFromPrivateMethod accessedFromPrivateMethod() {

return null;

}

public String accessedFromPrivateMethodBody() {

return new AccessedFromPrivateMethodBody().toString();

}

private Set<String> stuff(HashMap<String, String> map) {

System.out.println(new Foo());

return new HashSet<String>();

}

private class Foo {

// Hint: this field won't appear in the ClassAnalysis for SomeClass

public AccessedFromPrivateClassPublicField anotherField;

public String toString() {

return "" + new AccessedFromPrivateClass();

}

}

}

```

Changes the serialization format of `ClassAnalysis` + `DependentsSet`

Signed-off-by: Robert Stupp <snazy@snazy.de>

  1. … 9 more files in changeset.
Remove unused parameter and unused class

Accept a tiny performance regression

Rebaseline to accept a tiny regression

Rebaseline to lock up the performance improvements

Merge pull request #10401 from gradle/lptr/docs/compatibility-notes

Mention the Java, AGP and KGP versions Gradle is compatible with

Use the parent project's classloader scope as the child's parent scope

Fix classloader scopes

Move baseProjectClassLoaderScope from Settings to Gradle