Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Adjust tests and samples to new publishing default behavior

  1. … 43 more files in changeset.
wip - fix more tests

  1. … 46 more files in changeset.
wip - fix more tests

  1. … 45 more files in changeset.
wip - fix more tests

  1. … 46 more files in changeset.
Introduce ecosystem registration

This commit introduces the concept of "ecosystem", that can be

registered on an attributes schema. When a component is published,

it may provide a list of ecosystems. This list is used by consumers

when resolving. If, for some reason, variant resolution fails, and

that the consumer didn't use a plugin which provides the expected

ecosystem, the error message will indicate that they probably

miss a plugin that understands that ecosystem.

This is useful when a plugin extends an existing ecosystem with

additional attributes, that consumers may not be aware of. In

this case it is expected that the plugin declares an ecosystem.

Currently the error message will only indicate what ecosystem

is missing, and an optional description. It will not tell _how_

such plugin can be found, nor what plugins provide it.

By default, for adhoc components, publishing will use the

ecosystems of the producer. For example, for a Java project,

the published Gradle metadata file will include the java

ecosystem requirement.

For components which are not adhoc, they must implement the

`ComponentWithEcosystems` interface in order to tell which

ecosystems are in use.

  1. … 54 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.
Fix Java usage compatibility rule

There were a number of uncovered cases, which might lead to not finding a variant when a compatible one existed.

This was the case for example when asking for "Java API" and the only available variants are runtime.

  1. … 5 more files in changeset.
Make sure published platforms can be consumed as enforced platforms

This commit introduces a similar strategy to what we do with

Maven metadata, but for Gradle metadata, in order to force platforms.

In fact, it uses the same code path since Gradle metadata also makes

use of Maven immutable resolve metadata. The only difference then

happens at parse time where we generate synthetic copies of platform

variants.

  1. … 7 more files in changeset.
Minor edits.

  1. … 1 more file in changeset.
Test timestamped identifier for resolved snapshots

  1. … 4 more files in changeset.
Coverage for published constraint with reject '+'

- Test error message when required module is rejected

- Updated test fixtures to correctly produce module file with rich constraints

  1. … 8 more files in changeset.
Merge pull request #3609: Disable Maven2 legacy support for `maven-publish` plugin

When publishing with MavenDeployer we set the maven.metadata.legacy flag to ensure compatibility with Maven2. This changeset alters the default value for the `maven-publish` plugin, which provides less strong compatibility guarantees due to it's incubating status.

  1. … 3 more files in changeset.
Improve dependency constraints handling in Module test fixtures

  1. … 6 more files in changeset.
Improve test coverage for SNAPSHOT publishing

- Extract coverage into separate test case

- Verify maven-metadata.xml for snapshots

  1. … 8 more files in changeset.
Publish Gradle metadata on Ivy repositories

This commit adds support for publishing Gradle metadata on Ivy repositories. Existing tests haven't been

adapted yet.

  1. … 9 more files in changeset.
Add support for resolving strict dependencies from an Ivy repository

So far strict dependencies were only supported when resolving from a Maven repository. This commit adds

the necessary infrastructure to make it work on Ivy repositories too. It's worth noting that similarly

to Maven, as soon as Gradle metadata is used, variants from the original Ivy metadata file are "ignored",

and it's a lossy conversion.

This commit is a "make it work". There's still missing test coverage, and there's redundant code due

to the replication of what has been setup for the Maven repositories. Subsequent commits will fix that.

  1. … 41 more files in changeset.
Improve docs for `MavenModule.assertPublishedAsJavaModule()`

  1. … 1 more file in changeset.
Make `MavenModule.rootMetaData` more consistent with other artifacts

- Can now use it consistently with other resource fixtures

- Use in GCS/S3/SFTP maven-publish tests for consistency

  1. … 9 more files in changeset.
Enable Gradle metadata publishing for all maven-publish tests

- Several tests are still failing

- Most of these seem related to the fact that we don't respect the modified publication coordinates

- Some required verifications are missing

- Dependency excludes are not yet supported, so we do not verify these for module metadata

  1. … 19 more files in changeset.
Avoid multiple fixture instances when validating published Maven java libraries

  1. … 3 more files in changeset.
Extend metadata rules to allow adjustment of dependencies

This adds:

- withVariant(variant_name) {}:

Choose an existing variant (or

configuration) by name to modify its dependencies.

This hook can later be used to modify attributes of a variant.

- withVariant(variant_name) { withDependencies {} }:

Inside the withDependencies block, existing dependencies can be

removed and new dependencies can be added.

  1. … 34 more files in changeset.
Verify variant artifacts for published java component

  1. … 2 more files in changeset.
Some changes to `MavenModule` test fixtures to allow an artifact in a module to be defined using a path relative to the module directory, moved up some methods to more general interfaces, and some other tidy-ups.

  1. … 13 more files in changeset.
Retain classifier when transforming artifacts

Two artifacts coming from the same component, but

with different classifiers should result in two

distinguishable artifact identifiers after applying

an artifact transformation.

  1. … 3 more files in changeset.
Changed the Maven repository test fixtures to support publishing and resolving the Gradle module metadata.

  1. … 8 more files in changeset.
Some cleanup of the `MavenModule` test fixtures, to reduce the number of places the logic to calculate the location of a file in a maven repo is implemented. At least one such implementation was broken.

  1. … 5 more files in changeset.
Change repository test fixtures to allow the repository path and backing file of artifacts to be queried by test.

  1. … 17 more files in changeset.
Make `MavenMetadataLoader` use `CacheAwareExternalResourceAccessor`

This allows caching the calls to get `maven-metadata.xml`, and, since we now coordinate access to remote

resources through `CacheAwareExternalResourceAccessor`, reduce the number of remote calls in case several

projects are resolved in parallel: metadata loader honors the contract of not downloading the same

resource (`maven-metadata.xml`) concurrently.

  1. … 21 more files in changeset.
Added some int test coverage for interaction between Maven scopes and Ivy configurations.

  1. … 27 more files in changeset.
Converted a maven int test to use `ResolveTestFixture` to verify results.

  1. … 5 more files in changeset.