Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Fixed unit test on Windows.

    • -4
    • +5
Changed the `maven-publish` and `ivy-publish` plugins to do a better job of calculating the coordinates to use to represent a project dependency in the generated metadata files. Previously, the plugins would fail when there were multiple publications in the target project with different coordinates. Now, the plugins will ignore publications that contain the variants of some other component that is included in another publication.

The C++ plugins use this to inform the publishing plugins (and whatever else cares) which publication is the 'main' publication of the project. The main publication holds details of the component as a whole and is intended to be the 'entry point' for the component.

Using this allows a not-quite-correct workaround to be removed from the C++ plugins and that project dependencies are mapped to coordinates in a consistent way for both C++ and Java components, by shared logic.

    • -3
    • +76
  1. … 7 more files in changeset.
Revert De-duplicate commonly used immutable objects in dependency resolution and IDE changes

Commits reverted:

- 807b1e4f8d1585d93c1de3e9ca83d99d0819e2d2

- 9482b0b05374253cafdb776550d7016385912e04

- 4ecead06b53ec6b0f15c517bf0d0c6a74c3b3c05

- db1135a8a5f1c507e0df3c03ad12ddc963799e4d

- 7350bcbae30a777909cec74ebfd5a91d2c89081e

Additionally, minor changes to avoid usage of introduced

classes and methods from subsequent commits.

Issue: gradle/gradle-private#563

    • -2
    • +2
  1. … 109 more files in changeset.
De-duplicate (= intern) some instances in dependency resolution

- Reduce memory usage of dependency resolution by de-duplicating the

most commonly used immutable instances.

- Objects aren't strictly immutable: displayName is calculated lazily

- solution is thread-safe without synchronization

- lazy calculation is needed for efficient interning since a lookup

will always create a new instance.

- Use strong references in some instance interners

- strong references cause less GC overhead than weak references

- Strong references:







- Weak references:




- Both reference types:



- The reason for special handing is that DefaultBuildIdentifier

has a state field "current" as part of the instance which

isn't part of equals/hashCode.

+review REVIEW-6277

    • -2
    • +2
  1. … 104 more files in changeset.
Revert "Removed `ExtensionContainerInternal` type. It is not used for anything."

This reverts commit 7cbf09e12965fd07c12d4f2fd2600da87c7a25f2 which

caused problems for plugins using `ProjectInternal`.

    • -3
    • +2
  1. … 5 more files in changeset.
Removed `ExtensionContainerInternal` type. It is not used for anything.

    • -2
    • +3
  1. … 5 more files in changeset.
Make DirectInstantiator a singleton.

    • -1
    • +1
  1. … 89 more files in changeset.
Merge remote-tracking branch 'remotes/origin/release'

    • -4
    • +6
  1. … 11 more files in changeset.
GRADLE-2837: Ensure that a dependency project is fully evaluated before it is used by a referencing project in publishing

    • -4
    • +6
  1. … 4 more files in changeset.
Replaced PublicationCoordinates with ModuleVersionIdentifier.

    • -3
    • +5
  1. … 8 more files in changeset.
Project dependencies map to a single publication of the depended-on project - For single publication, use it - For multiple publications, fail unless all publications have the same coordinates - For no publications, use the project coordinates - Added ProjectDependencyPublicationResolver to do the work of determining the coordinates to use for a project dependency

    • -0
    • +130
  1. … 20 more files in changeset.