ApplicationPluginIntegrationTest.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fix task dependency inference when a mapped task output file `Property` is used as input to an `@Input` on another task.

Move some test utility methods out of the artifact transform tests into a more general place, and reuse in some of the task dependency inference tests.

    • -8
    • +8
    ./ApplicationPluginIntegrationTest.groovy
  1. … 28 more files in changeset.
Fix task dependency inference when a mapped task output file `Property` is used as input to an `@Input` on another task.

Move some test utility methods out of the artifact transform tests into a more general place, and reuse in some of the task dependency inference tests.

    • -8
    • +8
    ./ApplicationPluginIntegrationTest.groovy
  1. … 28 more files in changeset.
Fix task dependency inference when a mapped task output file `Property` is used as input to an `@Input` on another task.

Move some test utility methods out of the artifact transform tests into a more general place, and reuse in some of the task dependency inference tests.

    • -8
    • +8
    ./ApplicationPluginIntegrationTest.groovy
  1. … 28 more files in changeset.
Fix task dependency inference when a mapped task output file `Property` is used as input to an `@Input` on another task.

Move some test utility methods out of the artifact transform tests into a more general place, and reuse in some of the task dependency inference tests.

    • -8
    • +8
    ./ApplicationPluginIntegrationTest.groovy
  1. … 28 more files in changeset.
Fix task dependency inference when a mapped task output file `Property` is used as input to an `@Input` on another task.

Move some test utility methods out of the artifact transform tests into a more general place, and reuse in some of the task dependency inference tests.

    • -8
    • +8
    ./ApplicationPluginIntegrationTest.groovy
  1. … 28 more files in changeset.
Fix task dependency inference when a mapped task output file `Property` is used as input to an `@Input` on another task.

Move some test utility methods out of the artifact transform tests into a more general place, and reuse in some of the task dependency inference tests.

    • -8
    • +8
    ./ApplicationPluginIntegrationTest.groovy
  1. … 28 more files in changeset.
Fix task dependency inference when a mapped task output file `Property` is used as input to an `@Input` on another task.

Move some test utility methods out of the artifact transform tests into a more general place, and reuse in some of the task dependency inference tests.

    • -8
    • +8
    ./ApplicationPluginIntegrationTest.groovy
  1. … 28 more files in changeset.
Fix task dependency inference when a mapped task output file `Property` is used as input to an `@Input` on another task.

Move some test utility methods out of the artifact transform tests into a more general place, and reuse in some of the task dependency inference tests.

    • -8
    • +8
    ./ApplicationPluginIntegrationTest.groovy
  1. … 28 more files in changeset.
Use installDist as main task for application plugin

    • -1
    • +1
    ./ApplicationPluginIntegrationTest.groovy
Test app plugin like other well behaved plugins

The application plugin neither creates its tasks lazily nor references

other tasks lazily (e.g., the `jar` task). Making the

ApplicationPluginIntegrationTest inherit from WellBehavedPluginTest

exposes this problem by showing that the plugin fails the "does not

realize all possible tasks" test.

Signed-off-by: Kevin Macksamie <kevin.macksamie@gmail.com>

    • -2
    • +8
    ./ApplicationPluginIntegrationTest.groovy
Fix plugins usages of output test fixtures

    • -8
    • +8
    ./ApplicationPluginIntegrationTest.groovy
  1. … 8 more files in changeset.
Removed extraneous 'chmod' (#4779)

This fixes https://github.com/gradle/gradle/issues/4627

    • -0
    • +22
    ./ApplicationPluginIntegrationTest.groovy
  1. … 1 more file in changeset.
Add support for configurable start script directory

Signed-off-by: Bo Zhang <bo@gradle.com>

    • -0
    • +26
    ./ApplicationPluginIntegrationTest.groovy
  1. … 8 more files in changeset.
Improve code according to Lorant suggestion

    • -3
    • +3
    ./ApplicationPluginIntegrationTest.groovy
Address code review comments

    • -4
    • +30
    ./ApplicationPluginIntegrationTest.groovy
  1. … 2 more files in changeset.
Detect when classpath changes with application plugin

Fix issue gradle/gradle#1923

    • -10
    • +27
    ./ApplicationPluginIntegrationTest.groovy
  1. … 1 more file 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.

    • -6
    • +12
    ./ApplicationPluginIntegrationTest.groovy
  1. … 11 more files in changeset.
Merge pull request #1174 from gradle/so-java-library-test-usage

Make api/implementation work for testing too

    • -0
    • +100
    ./ApplicationPluginIntegrationTest.groovy
  1. … 3 more files in changeset.
Fix application plugin test that put files into build/ before the test runs

+review REVIEW-6424

    • -1
    • +1
    ./ApplicationPluginIntegrationTest.groovy
Make api/implementation work for testing too

The api/implementation configurations were ignored for test compilation and runtime

until now, meaning that all api dependencies were missing during compilation

and all implementation dependencies were missing at test runtime. Instead the default

configuration was used for both cases.

The fix was simply to add the usage attribute to the compile/runtime classpath configuration

of all sourceSets instead of just the main one.

    • -0
    • +100
    ./ApplicationPluginIntegrationTest.groovy
  1. … 3 more files in changeset.
Revert "Revert "Merge branch 'cc-java-library-plugin'""

This reverts commit c6cd884e1a8889fb25d26dfcfdfa79d896835e11.

    • -0
    • +57
    ./ApplicationPluginIntegrationTest.groovy
  1. … 76 more files in changeset.
Revert "Merge branch 'cc-java-library-plugin'"

This reverts commit 0d442a55b445f537efbce65267ce9418fce2e7a8, reversing

changes made to 04647ab69fc8d19186cd2a78124ea74b8a89cc0f.

    • -57
    • +0
    ./ApplicationPluginIntegrationTest.groovy
  1. … 76 more files in changeset.
Use `runtimeClasspath` instead of `runtime`

This commit fixes the `application` plugin to include all runtime dependencies in the generated distribution.

    • -0
    • +57
    ./ApplicationPluginIntegrationTest.groovy
  1. … 1 more file in changeset.
Add integration test that checks for correct Java PID

This reproduces the issue which lead to the discovery of #779.

An application start script should not spawn a new process when

starting `java`. This is checked here by comparing the process

IDs before and during `java` execution.

The integration test fails with 3.2-RC1 and 3.2-RC2.

    • -0
    • +20
    ./ApplicationPluginIntegrationTest.groovy
Use eval only for de-escaping arguments

This restores the original behaviour of using `exec` to call the `java`

command. Still, the use of a custom array is a voided by collecting

all arguments for `java` (including JVM options and Application

arguments) directly into the argument array $@ (`set --`).

    • -2
    • +2
    ./ApplicationPluginIntegrationTest.groovy
  1. … 2 more files in changeset.
Remove unnecessary quotes in unix start script

In particular the additional quotes of the $JAVACMD caused the script

to continue evaluation after the actual Gradle run. In the Gradleception

CI job, where the gradlew script was replaced by a new version of it

during the run, this caused an evaluation syntax error after the

(successful) build.

+review REVIEW-6284

    • -2
    • +2
    ./ApplicationPluginIntegrationTest.groovy
  1. … 2 more files in changeset.
Do quote escaping in unix start scripts the right way around

+review REVIEW-6284

    • -2
    • +2
    ./ApplicationPluginIntegrationTest.groovy
  1. … 2 more files in changeset.
Escape java command in unix start script

The command can contain spaces, as it can contain the path set

as JAVA_HOME. Because the script now uses 'eval' (instead of exec), the

'double escaping' is needed.

+review REVIEW-6284

    • -3
    • +39
    ./ApplicationPluginIntegrationTest.groovy
  1. … 2 more files in changeset.
Limit ourselves to /bin/sh (#621)

+review REVIEW-6235

    • -2
    • +2
    ./ApplicationPluginIntegrationTest.groovy
  1. … 3 more files in changeset.
Escape application arguments and JVM options

+review REVIEW-6235

    • -2
    • +2
    ./ApplicationPluginIntegrationTest.groovy
  1. … 1 more file in changeset.