MavenJavaModule.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Make Javadoc and sources primary variants without dependencies

  1. … 15 more files in changeset.
Make Javadoc and sources primary variants without dependencies

  1. … 15 more files in changeset.
Make Javadoc and sources primary variants without dependencies

  1. … 15 more files in changeset.
Make Javadoc and sources primary variants without dependencies

  1. … 15 more files in changeset.
Introduce multiple variations of MavenPublishJavaIntegTest

- only 'main' feature without docs

- only 'main' feature with docs

- multiple features without docs

- multiple features with docs

  1. … 5 more files in changeset.
Introduce multiple variations of MavenPublishJavaIntegTest

- only 'main' feature without docs

- only 'main' feature with docs

- multiple features without docs

- multiple features with docs

  1. … 5 more files in changeset.
Support testing with multiple features in MavenJavaModule fixture

  1. … 1 more file in changeset.
Support testing with multiple features in MavenJavaModule fixture

  1. … 1 more file in changeset.
Support testing with multiple features in MavenJavaModule fixture

  1. … 1 more file in changeset.
Prepare publishing fixtures and test to also test publication with docs

  1. … 3 more files in changeset.
Prepare publishing fixtures and test to also test publication with docs

  1. … 3 more files in changeset.
Prepare publishing fixtures and test to also test publication with docs

  1. … 3 more files in changeset.
Prepare publishing fixtures and test to also test publication with docs

  1. … 3 more files in changeset.
Do not change extension of published artifact based on pom packaging

We now publish the artifacts as they were defined in the build.

If the packaging and artifact extension should be aligned, this

can easily be done by adjusting the artifact extension when

building it (e.g. by utilizing jar.archiveExtension.set())

Before this change, Gradle Module Metadata was broken for artifacts

that were changed after the metadata file has been generated

(newly added 'MavenPublishPomPackagingJavaIntegTest' tests failed).

  1. … 3 more files in changeset.
Fix rebase glitches

  1. … 7 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.
Deprecate `JavaLibrary` in favor of public API

This commit makes use of the newly introduced software component

factory to support publishing of Java components using a public

API only.

There are a few consequences to this change, mostly around Gradle

metadata:

- variants `api` and `runtime` are now named `apiElements` and

`runtimeElements`

- it is no longer possible to warn the user when publishing a

variant without capability. This might change later if we decide

to _always_ publish capabilities (and optimize on read)

  1. … 22 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.
Add coverage for sequential publishing of Maven snapshots

This coverage exposes an issue with our previous implementation:

we do not correctly merge the <snapshotVersions> list in maven-metadata.xml.

While the new behaviour is not worse than the previous behaviour, it

does not address the issue reported at #2882.

  1. … 3 more files in changeset.
Purge some old TODOs

  1. … 8 more files in changeset.
Renamed `MavenPublishedJavaModule` -> `MavenJavaModule`

    • -0
    • +108
    ./MavenJavaModule.groovy
  1. … 2 more files in changeset.