ValidatingIvyPublisherTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fix for changes to service injection.

  1. … 1 more file in changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.

  1. … 32 more files in changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.

  1. … 32 more files in changeset.
Replace another usage of the `NamedObjectInstantiator` singleton with an injected service.

  1. … 32 more files in changeset.
Make `IvyPublisher` symmetrical with `MavenPublisher`

    • -13
    • +6
    ./ValidatingIvyPublisherTest.groovy
  1. … 5 more files in changeset.
Make `IvyPublisher` symmetrical with `MavenPublisher`

    • -13
    • +6
    ./ValidatingIvyPublisherTest.groovy
  1. … 5 more files in changeset.
Make `IvyPublisher` symmetrical with `MavenPublisher`

    • -13
    • +6
    ./ValidatingIvyPublisherTest.groovy
  1. … 5 more files in changeset.
Publication of resolved versions for Ivy xml

While the feature was added for the Gradle metadata linked to an Ivy

publication, it was missed for the Ivy xml itself.

This commit corrects that, relying on the usage context attributes to

map the Ivy dependency to the requested resolved configuration.

Fixes #8948

  1. … 11 more files in changeset.
Implement Gradle metadata marker in published pom/ivy files

This commit implements a performance optimization for Gradle metadata.

Given that today there's no library published in any repository with

Gradle metadata, it's much more likely to find a POM (or Ivy) metadata

file for an external dependency, rather than a Gradle metadata file.

If we decided to add `gradleMetadata()` sources by default to all

repositories, then we would probably introduce a performance regression

to a lot of builds, because we would first try to get Gradle metadata,

then fail, and search for POM/Ivy files.

To avoid this, whenever a library is going to be published with Gradle

metadata, we will introduce a _marker_ in the published POM or Ivy

file. When Gradle _resolves_ such a dependency, it will parse the POM

file and look for the marker. If it finds it, then it will _redirect_

to use Gradle metadata instead. This means that when Gradle metadata is

present, we will pay the price of looking for a POM or Ivy file first,

start parsing, only to discover we should parse Gradle metadata. This

should be ok in the beginning, knowing that if `gradleMetadata()` is

added, then we would systematically look at Gradle metadata first.

This means that this is a _temporary_ solution, until Gradle metadata

becomes widespread. So "temporary" should be understood as several

months, if not years.

The marker introduced in POM and Ivy files is _neutral_ for both Ivy

and Maven. By this we mean that it uses an XML comment. While not super

nice, we couldn't use a custom namespace because both Ivy and Maven

fail when parsing this. Properties were considered too, but Ivy doesn't

support them so for consistency both models use comments.

It's worth noting that we will still _completely parse_ the POM or Ivy

descriptor. It's a waste of time, but it helps in case we find a marker

but that for some reason the Gradle metadata file is absent. In this

case we fallback on the model we found.

This change also introduces a change in the semantics of the incubating

metadata sources API: those should be considered _hints_, and not strong

statements anymore.

Finally, should a producer want to avoid publishing Gradle metadata,

it's now possible to disable the task that creates the metadata file.

  1. … 57 more files in changeset.
Split off value snapshotting and attributes related methods of TestUtil

  1. … 64 more files in changeset.
Rework task dependency inference so that `Provider` implementations use the same `TaskDependencyContainer` interface that most other things use to declare their producer task to the task resolution infrastructure, rather than having special knowledge sprinkled around various places.

Cleaned up a bunch of `Provider` and `Property` implementations so that more logic is reused rather than reimplemented.

  1. … 30 more files in changeset.
Support propagation of the producer task for provider instances that are created using `Provider.map()`.

Now, when a provider represents a task or task output, whether mapped or not, that task is taken as the producer of the value and the mapping function is not called. Otherwise, the value of the provider is unpacked and resolved, as it previously was.

Rework the protocol by which providers communicate their build dependencies to consumers.

  1. … 34 more files in changeset.
Make IvyArtifact lazy

  1. … 13 more files in changeset.
Remove special treatment for Gradle module descriptor from Ivy publishing

Issue: #4943

    • -31
    • +19
    ./ValidatingIvyPublisherTest.groovy
  1. … 4 more files in changeset.
Fix build

    • -23
    • +29
    ./ValidatingIvyPublisherTest.groovy
  1. … 16 more files in changeset.
Initial implementation of component metadata rules allowing modification of variant attributes

This commit introduces metadata rules that support modification of variant attributes. Variant attributes

are specific to each variant and can be found in module metadata. Those are NOT component level attributes,

which could be used during dependency resolution. This will be added in a subsequent commit.

  1. … 49 more files in changeset.
Create all mutable Ivy module resolve metadata through factory

This will simplify the injection of services through the factory, when we will need the immutable

attributes factory to be pushed to resolve metadata.

  1. … 26 more files in changeset.
Make java libraries publishable on Ivy using Gradle metadata

This commit completes Gradle metadata publishing on Ivy repositories. It adds the necessary support, and

converts several tests to the wrapping `javaLibrary` test fixture.

    • -13
    • +18
    ./ValidatingIvyPublisherTest.groovy
  1. … 28 more files in changeset.
Merged the file resource implementation for the public `Resource` API into the file resource implementation for `ExternalResource` used by dependency resolution and publishing. This is a small step towards merging and reusing all the various resource implementations.

  1. … 30 more files in changeset.
Moved `FileResourceConnector` from 'dependencyManagement' to 'resources' project.

  1. … 10 more files in changeset.
Added `FileResourceRepository` as a global service for creating various file backed `ExternalResource` implementations. Use this in various places instead of creating these implementations directly.

  1. … 41 more files in changeset.
Replaced `ExternalResourceRepository.getResourceMetaData()` with `ExternalResource.getMetaData()`.

Also changed the file backed implementation of `ExternalResource` to use `FileSystem.stat()` to calculate the file meta-data, rather than using the `File` API.

  1. … 50 more files in changeset.
Detangle ivy module descriptor parser

This commit removes the Ivy module descriptor parser as a service, because it unfortunately introduced

a lot of tangling between projects, making it necessary to introduce `project(':ivy')` as a dependency

to almost all projects.

This commit removes the parser as a service and creates it on demand. It should not have a big impact

on performance since there should be only one instance in global scope, through `IvyResolver`.

  1. … 19 more files in changeset.
Cache module version identifiers

In a similar way to module identifiers, use the module identifier factory to cache the module version identifiers.

It allows faster comparisons as we will hit `a==b` much more often and don't have to go the `equals` route. There

are still places where the factory is not used, but it doesn't seem to have a huge impact on performance.

  1. … 49 more files in changeset.
Use the module identifier factory during ivy parsing

  1. … 23 more files in changeset.
Restored some ivy.xml validation that went missing and added some more.

  1. … 4 more files in changeset.
Ignored broken test temporarily

Cleanup test outputs for unit tests in 'ivy' subproject

    • -12
    • +20
    ./ValidatingIvyPublisherTest.groovy
  1. … 2 more files in changeset.
Fixed the location reported when a pom or ivy.xml cannot be parsed so that it points to the origin of the resource, not the cached file.

Also changed the error message to use file path for an origin that is on the file system and a URI for a remote origin. Plus added some test coverage for this.

  1. … 4 more files in changeset.
Review items for 'Make branch attribute available when publishing and resolving Ivy modules' story

- Changed groovy.xml.QName to javax.xml.namespace.QName

- Minor change to error message and construction of namespace list

- Minor change to dsl doc

- Changed IvyModuleDescriptorSpec to return mutable view of IvyExtraInfoSpec

- Minor change to sample build script

+review REVIEW-5059

  1. … 18 more files in changeset.