Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Build buildSrc after applying the settings file (#10305)

Fixes #9094 and #5333

  1. … 40 more files in changeset.
Update released version to latest snapshot

Update library versions in build init to latest for 6.1

Update version to 6.1

Clean release notes and welcome message for 6.1

    • -74
    • +3
    /subprojects/docs/src/docs/release/notes.md
Clean accepted API changes

Try again to correct the classloader structure for projects

Use the base project loader as the base loader for all projects

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.