Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add `status` to Gradle module metadata

This commit adds attributes to top level component in Gradle metadata. Attributes are written to Gradle metadata files,

and when read, some attributes can be mapped to existing, legacy, properties of component metadata. This is the case

for the "status" property, which is now mapped to a component attribute when serializing, and mapped back to the "status"

property when reading.

This commit also introduces a test that makes sure that the status is actually read from the Gradle metadata file, by

totally ignoring the Ivy descriptor.

  1. … 18 more files in changeset.
Remove `getVersionConstraint` from `Dependency`

We will at some point deprecate `getVersion` on `Dependency`, which is nullable because it doesn't always

make sense (ex: project dependencies). So instead of having version constraints on dependency, it will

only be introduced on the relevant type (external dependencies only).

  1. … 8 more files in changeset.
Read and write `prefers` and `rejects` version constraints in Gradle metadata file

This commit changes the Gradle metadata file format to write version constraints instead of versions.

Instead of writing a single (preferred) version, the `version` block in the Gradle metadata format

for a dependency is now a proper `VersionConstraint`, with `prefers` and `rejects`.

The Gradle dependency metadata format spec has been adjusted.

Note that this commit does not introduce publishing of such metadata (at least, it doesn't prove that

it works): it only adds support for the feature.

  1. … 8 more files in changeset.
Remove maven assumption from module file generator

The ModuleMetadataFileGenerator now asks the backing publication for

the published name and url for each `PublishArtifact`.

  1. … 4 more files in changeset.
Fixed generation of the module metadata file for project dependencies that point to another project that has publications whose coordinates have been customized.

  1. … 4 more files in changeset.
Renamed the module metadata file in a Maven repo from `x-module.json` to `x.module`.

  1. … 9 more files in changeset.
Changed the dependency resolution engine to understand to some degree the connections between the various modules of a component that is published across multiple modules, such as a C++ library or executable.

The publishing plugins no longer insert an artificial dependency between the main module and the other modules. The module metadata parser does this instead when it reads the metadata. This implementation is intentionally dumb and can be improved later without requiring changes to the metadata.

  1. … 7 more files in changeset.
Removed unused import.

Include more details in the module metadata file.

- Added the identity of the component contained in the current module, if any.

- Added connection back to the main module of the component, where the current module is not the main module.

- Added connection to the module that contains each variant, when the variant is not contained in the current module.

- Added size and content information for each file.

  1. … 7 more files in changeset.
Moved responsibility for generating the correct module metadata for a component that is published across multiple modules into the publish plugins, instead of hacking this together in the C++ plugin. The implementation is arguably still hackey but is now in a better home, where it can be reused by other plugins.

The module metadata generated for published C++ executables now includes the correct references to the debug and release variants, which are published to separate modules.

  1. … 7 more files in changeset.
Include all attributes of each variant of a C++ component in the generated module metadata files published to Maven repositories. Previously only the usage attribute was included.

Added support for attributes with boolean and String values in the generated module metadata file. Previously only `Usage` was supported.

Include the release variants of a published C++ library in the module metadata of the main Maven module. Previously only the API and debug variants were included (because the debuggable attribute could not be expressed in the metadata).

This change means that the correct debug/release variant of a C++ library resolved from a Maven repository will be selected for linking.

  1. … 20 more files in changeset.
Implement static library and statically linked executable

  1. … 37 more files in changeset.
Removed `ChildComponent` concept, as it is not required.

  1. … 11 more files in changeset.
Changed the module metadata file to include the dependencies for each variant. Currently only the group, module and version properties of each dependency is included. Other information such as exclusions, artifacts and so on are not included. These may be added later.

Changed the version of the format to '0.2'.

  1. … 8 more files in changeset.
Fixed the name of the 'usage' attribute in generated module metadata file so that it matches that used by the C++ and JVM plugins.

  1. … 1 more file in changeset.
Changed dependency resolution to parse the Gradle module metadata file if present. The result (except for a failure) is ignored for now.

  1. … 8 more files in changeset.
Initial changes to dependency resolution to use the Gradle module metadata file when present. The file is downloaded and cached when present, but not used yet.

Added a temporary internal flag on `MavenRepository` to enable this behaviour, which is disabled by default. The C++ plugins switch this on.

  1. … 14 more files in changeset.
Include the list of files for each variant of a component in the generated Gradle metadata file included in a published Maven module.

  1. … 8 more files in changeset.
Include the list of variants for a component in the generated Gradle metadata file included in a published Maven module.

  1. … 12 more files in changeset.
Fixed unit test on Windows.

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.

  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

  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:

DefaultModuleIdentifier

DefaultModuleVersionIdentifier

DefaultModuleVersionSelector

DefaultModuleComponentIdentifier

DefaultModuleComponentSelector

DefaultProjectComponentSelector

- Weak references:

DefaultLibraryBinaryIdentifier

DefaultLibraryComponentSelector

DefaultIvyArtifactName

- Both reference types:

DefaultBuildIdentifier

DefaultProjectComponentIdentifier

- 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

  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`.

  1. … 5 more files in changeset.
Removed `ExtensionContainerInternal` type. It is not used for anything.

  1. … 5 more files in changeset.
Fix some tests that were leaking file handles

  1. … 18 more files in changeset.
Don't use common parent class for now

  1. … 12 more files in changeset.
Introduce test fixture of tests using ProjectBuilder

Automatically uses and cleans up temporary project directory.

  1. … 13 more files in changeset.
Make DirectInstantiator a singleton.

  1. … 89 more files in changeset.
Deprecate PluginContainer.apply(Class) and PluginContainer.apply(String)

+review REVIEW-5239

  1. … 101 more files in changeset.