Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Make MavenProjectIdentity live

This way the coordinates are only evaluated when needed.

Previously they were evaluated when a publicaiton was created.

Lots of users had worked around it by re-setting the values

to what should already be the defaults later.

Improve wording in IDEA Plugin chapter

Merge pull request #5071 from gradle/oehme/performance/cached-resource-lookups

Cache resources in caching classloader

Merge pull request #5072 from gradle/oehme/performance/external-module-lookup

Cache external module lookups

Merge pull request #5083 from gradle/oehme/performance/faster-mirror

Make mirror init script faster

Update wrappers to latest snapshot distro

Add test for sample

Merge pull request #826 from gradle/bamboo/integ-tests

Make generated precompiled script plugin code follow the kotlin-dsl coding conventions

Mark offending test with `@LeaksFileHandles`

Merge pull request #825 from gradle/eskatos/idea/gradle-idea-ext-plugin

Use idea-ext plugin experiment

Use umodifiable list in DefaultClassPath

This makes accidental mutation impossible and reduces some

of the repeated wrapping.

  1. … 23 more files in changeset.
Update Gradle perf baseline to commit that does not use snapshot build scan plugin

    • -1
    • +1
Replace locking with concurrent map

DependencyClassPathNotationConverter didn't need pessimistic locking

as the protected operation is not expensive. Use a concurrent map instead.

Use idea-ext plugin

- license header

- disable unwanted frameworks detection

Remove ext-releases-local repo as its included in the libs-releases repo

Defer gradleApi classpath lookup to execution time

It is only needed when the gradleApi file collection is constructed.

Restore correct locking in DependencyClassPathNotationConverter

This was broken when making the creation lazy, protecting the

creation method (which needs no lock) instead of the cache access

(which does need a lock).

Explain that IDEA import honors IDEA configuration

Clarify that IDEA's import facility doesn't require the build script to apply

the IDEA Plugin, but it will honor some forms of IDEA configuration if it does.

Add model test for script plugin with a buildscript block

See #110

Process the `buildscript` block of project script plugins

See #180

Improve explanation of `api` vs `implementation` in manual

I've reordered a one or two things and attempted to bring a little more clarity

to this topic in the Java Library Plugin chapter of the user manual. I have

also linked directly to this particular section from the main Building Java

projects chapter so that it gets more attention.

Replace gradle-build-internal with ext-releases-local repo

Remove gradle-build-internal repository

Reuse `joinLines` extension

Rename immutable file collection methods

* `ProjectLayout.filesFor()` -> `files()` (we already have `file()` and we are replacing `Project.files()`, moreover the `For` suffix doesn't seem to add anything)

* `ProjectLayout.mutableFilesFor()` -> `configurableFiles()` (the result is of type `ConfigurableFileCollection`, and we regularly use "configure" as a term in our public APIs, while we don't use "mutate")

Publish configuration-wide excludes in Gradle module metadata

Resolves #5035.

Remove duplication

Make mirror init script faster

Using dynamic Groovy had a noticable effect on some scenarios.

Use CompileStatic instead to reduce noise in the profiling results.

Merge branch 'release'

Upgrade wrapper to 4.7

    • -1
    • +1