Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Use CLASSPATH instead of -cp

Avoid accidental class leakage

By implementing the action in Groovy, the get gradle action

class was leaking internal JAX classes during serialization.

Publish 6.1.1-20200125053554+0000

Recognize contributor

    • -0
    • +1
    /subprojects/docs/src/docs/release/notes.md
Merge remote-tracking branch 'origin/release'

* origin/release:

Update to 6.1.1

Polish release notes with Polish review

Tweak release features too

Polish release notes

Clarify the compatibility aspect of dependency cache

Add more details to compile task ordering

Rework paragraph on compilation tasks dependencies

Rework paragraph about dependency cache relocation

Correct wrapper version in built samples

Update to 6.1.1

    • -1
    • +1
    /gradle/wrapper/gradle-wrapper.properties
Publish 6.1.1

Merge pull request #11991 from gradle/jjohannes/reselection-issue

Fix reselection bug and re-activate reselection on selector removal

Merge pull request #11993 from friederbluemle/fix-file-mode

Remove executable bit from non-executable files

Trust the tooling API jars

Polish release notes with Polish review

    • -2
    • +3
    /subprojects/docs/src/docs/release/notes.md
Tweak release features too

Polish release notes

    • -11
    • +10
    /subprojects/docs/src/docs/release/notes.md
Make sure the parent directory exists

Improve docker detection using test containers

Properly isolate tests from the Gradle user home

When running Gradle, we use the current working directory as the

base directory for searching a `settings.gradle` file. For tooling

API tests this working directory is the one of Gradle itself, which

causes a number of issues because the root directory of the project

doesn't match the working directory.

Therefore, Gradle finds the `settings.gradle` file of its own build,

instead of finding the one in the test.

As a workaround, TAPI tests now use an action which will set the

working directory to the test directory, which should cover most

cases. Additional cases like missing settings files in projects

under tests have to be handled separately, as demonstrated in this

commit for the ProjectBuilder test.

Publish 6.1.1-20200124111952+0000

Clarify the compatibility aspect of dependency cache

Add more details to compile task ordering

Make it explicit how classpath property and directory references are

what causes the task dependencies.

    • -1
    • +1
    /subprojects/docs/src/docs/release/notes.md
Revert "Publish 6.1.1-20200124000049+0000"

So the cross version tests don't use the latest 6.1.1

version which currently breaks the tests.

This reverts commit ea25260bcba92cf4121bb473b2e19db90ef08cd9.

Revert "Workaround for a bug in 6.1.x"

This reverts commit 3fea04408e90be62b0bda2ac09b3bcb1e9319cc3.

Workaround for a bug in 6.1.x

The bug (#11971) makes the build under test, called by the TAPI,

fail because the working directory is the working directory of

Gradle itself. This causes the test to try to read the verification

metadata file of Gradle itself, which exists, instead of not finding

any verification file like it should, because the build under test

doesn't have any.

The workaround is to change the working directory from the build

under test.

Merge branch 'master' of github.com:gradle/gradle

Publish 6.1.1-20200124000049+0000

Remove executable bit from non-executable files

Signed-off-by: Frieder Bluemle <frieder.bluemle@gmail.com>

Reactivate reselection on selector removal

Fixes #6567

The remaining issue reported in #11789 is fixed by the previous commit.

Fix re-selection cycle with endorsing parent nodes

Fixes issue reported in this comment:

https://github.com/gradle/gradle/issues/11789#issuecomment-572777215

Add test to reproduce exception on re-selection

https://github.com/gradle/gradle/issues/11789#issuecomment-572777215

Add test case for read-only cache with containers

This commit introduces a test case to check that it's actually

possible to run concurrent docker containers using the same

shared, read-only, dependency cache. It acts both as a test

case and documentation, as mounting the cache as a read-only

volume in Docker is the recommended behavior.

  1. … 4 more files in changeset.
Merge branch 'release' into cc/dm/issue-11971-merge