JavaPluginTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Revert "Introduce 'annotationProcessorClasspath' configuration"

This reverts commit 444a899c9cf4c968ce6a490d8148f35a1d631795 and

follow up changes to the annotation processing configurations.

  1. … 11 more files in changeset.
Introduce 'annotationProcessorClasspath' configuration

  1. … 9 more files in changeset.
Introduce 'annotationProcessorClasspath' configuration

  1. … 9 more files in changeset.
Introduce 'annotationProcessorClasspath' configuration

  1. … 9 more files in changeset.
Introduce 'annotationProcessorClasspath' configuration

  1. … 9 more files in changeset.
Introduce 'annotationProcessorClasspath' configuration

  1. … 9 more files in changeset.
WIP - adjustments + handle annotation processor configurations

  1. … 22 more files in changeset.
WIP - adjustments + handle annotation processor configurations

  1. … 24 more files in changeset.
WIP - adjustments + handle annotation processor configruations

  1. … 22 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 annotation processor generated sources to SourceSetOutput

Signed-off-by: Thomas Broyer <t.broyer@ltgt.net>

  1. … 9 more files in changeset.
Set default value to annotationProcessorGeneratedSourcesDirectory

This also fixes the documentation for the options.annotationProcessorPath

default value.

Fixes #4956

Signed-off-by: Thomas Broyer <t.broyer@ltgt.net>

  1. … 10 more files in changeset.
Always use configured annotationProcessorPath

- Don't use an empty path for `-proc:none` because it is also used by

compiler plugins

- Don't support setting it to `null` anymore.

Resolves #6573.

  1. … 11 more files in changeset.
Use LazyPublishArtifact for lazy archive tasks

  1. … 15 more files in changeset.
Dogfood ImmutableFileCollection on production code (#4988)

This reverts commit 13eaebc2b1244511dcbff4c59cd41253e3b69642.

  1. … 88 more files in changeset.
Revert "Dogfood ImmutableFileCollection on production code (#4988)"

This reverts commit 834632674ca29b6fd190857947338b2b54a9bb62.

The commit caused a bug in incremental compilation, causing changes

to go undetected.

  1. … 88 more files in changeset.
Dogfood ImmutableFileCollection on production code (#4988)

Use ImmutableFileCollection in production code

  1. … 88 more files in changeset.
Add annotationProcessor configurations for each SourceSet

And configure the compileJava.options.annotationProcessorPath

to use the configuration when not empty (and use 'null' when

the configuration is empty to preserve the current behavior).

Part of #2300

Signed-off-by: Thomas Broyer <t.broyer@ltgt.net>

  1. … 21 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.
Remove redundant extends from compile for apiElements (#2087)

The `JavaBasePlugin` already states taht `runtime` extends from

`compile`, so it is sufficient to say that `apiElements` extends from

`runtime` (which also includes `compile`) so you don't also need to

say it extends from `compile.`

  1. … 2 more files in changeset.
Changed the JVM plugins to use the public `ObjectFactory` API to create `Usage` instances, and removed the internal `Usages` class.

  1. … 13 more files in changeset.
Use separate output directories for all JVM languages

- Introduce an outputDir on SourceDirectorySet

- Default output directory is now `build/classes/<source directory set name>/<source set name>`

- Example: Java compilation goes to build/classes/java/main instead of build/classes/main

- Adapt JDepend, FindBugs, Test and ValidateTaskProperties tasks to handle multiple class directories

- Deprecate setClassesDir/getClassesDir on SourceSetOutput

- Calling setClassesDir restores old behavior (shared output directory)

- Introduce addClassesDir and getClassesDirs on SourceSetOutput

- OSGi plugin needs a single classes directory, so introduce 'osgiClasses' task that syncs all classes to a single directory

Most of the changes to integration tests are find classes in their new location. Helper methods in AbstractIntegrationSpec

can locate class files vs hardcoding a path.

Squashed commit of sg-split-jvm-classes branch for REVIEW-6502

  1. … 119 more files in changeset.
Default to compileClasspath for dependencyInsight task

Issue: #1376

  1. … 3 more files in changeset.
Let default extend from runtimeElements

The runtimeElements configuration contains what downstream projects

are supposed to consume and is thus a better default than the

runtimeClasspath configuration which is meant for the project's internal

usage.

  1. … 2 more files in changeset.
Fix backwards compatibility of new Java configurations

When a `java` or `java-library` project is referenced from another project

that doesn't know about the `usage` attribute, then all runtime dependencies

need to be exposed. This is necessary e.g. when packaging EARs or applications.

At the same time we want to have the minimal set of leaked dependencies for

consumers that do know about `usage`. The solution is to move the `apiElements`

configuration up to the `java` plugin and let it contain `compile` and `runtime`

for backwards compatibility. The `default` configuration contains everything on the

`runtimeClasspath`.

Once `compile` and `runtime` have been removed in some future Gradle version,

we will have exactly what we want: An empty API for `java` projects and only

exposing the `api` configuration for `java-library` projects.

  1. … 11 more files in changeset.
Adjust documentation to new compileOnly behavior

  1. … 9 more files in changeset.
Remove accidentaly `compileOnly extendsFrom compile`

This was an oversight when we implemented compileOnly dependencies.

In a first iteration `compileOnly` was set as the sourceSet's compile classpath.

We later changed this and introduced the `compileClasspath` configuration to better

split these concerns. At that point we forgot to remove the extends relationship

from compileOnly. The result is that there is no convenient way to query for all

dependencies that are indeed "compile only".

After this change users can now resolve `compileOnly` and actually only get the

dependencies that are used during compilation only, instead of also getting the

`compile` dependencies.

  1. … 6 more files in changeset.
Revert "Revert "Merge branch 'cc-java-library-plugin'""

This reverts commit c6cd884e1a8889fb25d26dfcfdfa79d896835e11.

  1. … 76 more files in changeset.
Revert "Merge branch 'cc-java-library-plugin'"

This reverts commit 0d442a55b445f537efbce65267ce9418fce2e7a8, reversing

changes made to 04647ab69fc8d19186cd2a78124ea74b8a89cc0f.

  1. … 76 more files in changeset.
Re-wire `runtimeOnly` configuration

As discussed in https://github.com/gradle/performance/issues/120#issuecomment-265610105,

this commit rewires the `runtimeOnly` configuration so that it is exported in `runtimeElements`.

It is assumed that if a user wants non-exported runtime dependencies, then they have to create their own configuration and make `runtimeClasspath`

extend from it.

  1. … 2 more files in changeset.