IvyJavaModule.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Extend test fixture for testing artifact selectors in GMM

  1. … 9 more files in changeset.
Clean up IvyPublication and publish more information to ivy.xml metadata

This cleans up the implementation of `populateFromComponent()` and

introduces the following changes that publish information which

was lossy before:

- Artifacts are now added to all configurations they belong to and

not just the first found

- Dependencies are now added for all configurations they belong to,

with the corresponding mapping and version, and

not just for the first found

- For a Java library, this means the 'runtime' now represents the full

runtime variant of the library (before, only 'default' represented

that)

  1. … 15 more files in changeset.
To avoid confusion, remove mention of "platform" from "target Java platform"

We already have the "Java Platform" plugin which is something quite

different from the concept we want to express when using "target java platform".

This is more often known as the "JVM version", or "target Java version". We

use "JVM" because this is not specific to Java.

  1. … 25 more files in changeset.
Rename the Java target platform attribute

This is to avoid confusion: while "minimal" makes sense from

the producer point of view, it reads strange when seen from

the consumer side: the "minimal" version here can be higher

than what a producer has. So it's now simplified to "target

platform".

  1. … 15 more files in changeset.
Introduce `TargetJavaPlatform` attribute

This commit adds a new Java ecosystem attribute, corresponding

to the minimal target platform a producer supports. It's often

the case that Java libraries are published with different

classifiers for different target platforms. However, a classifier

is not enough. With this attribute, we now have a proper model

of the producer and consumer side.

By default, the producer will not ask for a specific target

platform, but will only accept those which are lower than or

equal to the current Gradle runtime version. However, if the

consumer says something, it will then select the most appropriate

variant based on the producer attributes.

In the Java world, a consumer can use Java libraries produced

for older versions of Java, but not newer versions. This rule

is baked in as the default compatibility rule. Disambiguation

will then chose the closest version.

  1. … 23 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 Ivy tests after variant renaming

  1. … 3 more files in changeset.
Add `JavaLibraryPlatform` component that includes dependencies without artifact

This permits the publishing of a 'BOM', defined as a set of dependencies and

constraints without an associated artifact. When published to Maven metadata, will

have packaging = 'pom'.

This is only a partial solution to defining a 'java-library-platform':

- The producing project will still generate a Jar artifact, it just isn't published.

- When consuming as a project dependency, the Jar artifact is still included

- When consuming in a composite build, the Jar artifact is still included

  1. … 6 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.

    • -0
    • +126
    ./IvyJavaModule.groovy
  1. … 28 more files in changeset.