Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Upgrade jackson to 2.8.10

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

Simplify `ResourceVersionLister`

- Removed the internal visitor implementation.

- Update unit test coverage.

Signed-off-by: Daz DeBoer <daz@gradle.com>

Added a type parameter to `SwiftBinaryContainer` to represent the type of elements in the container.

Delegate metadata-missing version listing to metadata source

When Gradle fails to list versions using either `maven-metadata.xml`

or listing directories with `ivyPatterns`, the fallback behaviour is

to inspect all `artifactPatterns` to attempt to determine the

available versions. This is particular useful for `flatDir` repositories,

where Gradle will list artifacts by pattern and parse out the versions.

This behaviour has been move to the `DefaultArtifactMetadataSource`.

Signed-off-by: Daz DeBoer <daz@gradle.com>

Delegate Ivy version listing to metadata source

For an Ivy repository, there is no equivalent to `maven-metadata.xml`.

Instead, Gradle will use the `ivyPattern` to list the available

versions. This logic has been moved to `DefaultIvyDescriptorMetadataSource`.

Signed-off-by: Daz DeBoer <daz@gradle.com>

Changed the `SwiftBinaryContainer` implementation to enforce a basic lifecycle for each element in the container, so that an element cannot be seen outside the container until it has been configured. Also enforces a basic lifecycle for the container itself, so that further elements cannot be added once the elements are visible outside the container.

Elements are no longer configured when added to the collection and instead configured later, as a step towards configuring elements only as required.

Search only for one artifact when version listing

If a dependency declaration includes multiple target artifacts, we now

only use the first artifact name in order to list versions (when no

metadata files are present). Previously, we'd list versions that exist

with _any_ artifact pattern.

While this is theoretically a breaking change, there are a number of

factors that mean any change to behaviour is unlikely:

- For standard `maven` repositories, the `maven-metadata.xml` file is used

to list versions.

- For standard `ivy` repositories, the `ivy.xml` file pattern is used to

list versions.

- Even without any metadata files, when using a standard repository layout 2

dependency artifacts will result in the same version listing pattern.

The exception is with `flatDir` repositories, which have no revision directory.

There are further mitigating factors:

- Dependency artifacts are unlikely to be widely used, except as a mechanism to support

the setting of `classifier` or `extension` on a dependency. In these cases,

only a single dependency artifact will result.

- In the rare case where 2 dependency artifacts are present, both must exist for resolution

to succeed. So the previous behaviour would have listed versions that could not be resolved.

I feel this is very unlikely to cause any issues in the real world.

Signed-off-by: Daz DeBoer <daz@gradle.com>

Use `MavenVersionLister` in metadata source

This commit starts to move the logic for version listing into

the `MetadataSource` implementations. With this change, the

responsibility for loading maven-metadata.xml is with the

`DefaultMavenPomMetadataSource`.

Subsequent commits will merge version listing for ivy and artifact

metadata sources, simplifying `ExternalResourceResolver`.

Signed-off-by: Daz DeBoer <daz@gradle.com>

  1. … 3 more files in changeset.
Merge v0.13.1 into master and upgrade wrappers to Gradle 4.4

    • -1
    • +1
    /gradle/wrapper/gradle-wrapper.properties
  1. … 22 more files in changeset.
Enable caching for ANTLR task (#3778)

Merge pull request #3781 from gradle/bamboo/release/kotlin-dsl-0.13.2

Upgrade kotlin-dsl {0.13.1 => 0.13.2}

Merge pull request #3776 from gradle/dd/dependency-management/generate-maven-bom

Generate Maven BOM for `components.javaLibraryPlatform`

Merge pull request #3758 from gradle/sg/native/vcs-multi-project

Support multi-project source dependencies

Always lock around registry state changes

Let Maven and Ivy module fixture provide java library variants

Add ANTLR task to list of cacheable tasks

Add tests for all supported ANTTLR versions

Move module map details to a nested type

Deprecates specifying a processorpath in the compilerArgs

We don't want users doing that so that we can correctly cache

their tasks. But, we also don't want to break them as they migrate

from passing the processorpath command line argument via the

annotationProcessorPath property on CompileOptions.

Part of #2300

Signed-off-by: Thomas Broyer <t.broyer@ltgt.net>

Generate basic build files using BuildScriptBuilder

instead of file templates.

Remove commented clutter from generated file.

Signed-off-by: Paul Merlin <paul@gradle.com>

Add more explanations to performance-critical classes

Polish based on review feedback

Generate settings files using BuildScriptBuilder

instead of file templates.

Signed-off-by: Paul Merlin <paul@gradle.com>

Simplify BuildScriptBuilder default header comment

to make it generic enough so it can be applied to settings files.

Signed-off-by: Paul Merlin <paul@gradle.com>

Merge pull request #3754 from gradle/oehme/performance/config-time

Faster Android sync time

Merge pull request #3763 from gradle/oehme/performance/service-registry

Make ServiceRegistry simpler and faster

Revert changes to Maven2Gradle

and account for not supporting the Kotlin DSL when migrating from Maven

builds.

Signed-off-by: Paul Merlin <paul@gradle.com>

    • -1
    • +1
    /subprojects/docs/src/docs/release/notes.md
Move clean-up work to DefaultCancellableOperationManager

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

Fixed unit test on Windows.

Added a couple of query methods to `SwiftBinaryContainer` to locate a binary by name or by criteria represented by a `Spec`.