testFixtures

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Add some test coverage to verify that each of the IDE plugins can be applied to `buildSrc`.

Start growing some cross-cutting test coverage for the IDE plugins, so the plugins can become less different to each other.

    • -0
    • +21
    ./groovy/org/gradle/plugins/ide/fixtures/IdeWorkspaceFixture.java
  1. … 10 more files in changeset.
Fixes to ensure that `gradle :idea` generates all of the modules that are referenced in the IDEA project and so produces a functional IDEA project. Previously, this was working by assuming that a user would always run `gradle idea` and would never write or use any automation that happened to invoke `:idea`. This change fixes `gradle openIdea` to generate a functional IDEA project for multi-project builds.

Added a bunch of test coverage to ensure that `gradle :idea` does not generate too much stuff as well, when modules are excluded from the project.

  1. … 4 more files in changeset.
Pull methods up to `IdePlugin` from `XcodePlugin`

Signed-off-by: Daniel Lacasse <daniel@gradle.com>

  1. … 7 more files in changeset.
More tests for IDEA de-duplication in composite

- Test IML dependencies when module names are de-duplicated

- Test de-duplication when not all projects have 'idea' plugin applied.

(Not yet implemented: see gradle/composite-builds#99)

  1. … 1 more file in changeset.
Simplify IDEA scope mapping

The old scope mapping code was hardcoded, hard to understand and exploded in complexity

each time we added a new configuration to the Java plugin. It was doing this hardcoded

mapping in an attempt to minimize the number of dependency declarations in IDEA, e.g.

remove `testRuntime` dependencies from the `TEST` scope if they were already in the `RUNTIME`

scope and not present in `testCompile`. While this slightly reduces the number of false positives

in auto completion, it is hard to follow, as IDEA itself simply does not differentiate between

"test compilation" and "test runtime".

The new implementation accepts IDEA's dependency model and does the simples possible mapping to it:

- no hardcoded mapping rules for the Java plugin

- users can put dependencies into the 4 IDEA scopes (`COMPILE`,`PROVIDED`,`RUNTIME`, `TEST`)

- the IdeaPlugin uses the same API for adding dependencies that the user would use

- those scopes are not postprocessed in any way

The default mapping for the Java plugin is simplified to:

- `COMPILE` is empty

- `PROVIDED` = `compileClasspath`

- `RUNTIME` = `runtimeClasspath`

- `TEST`= `testCompileClasspath + testRuntimeClasspath`

The benefit of this mapping is that we no longer use `minus` configurations, which we might want

to deprecate/remove as well.

  1. … 20 more files in changeset.
Generated idea configuration respects module name settings #composite-builds

  1. … 2 more files in changeset.
Idea project for composite includes modules for every project in composite

  1. … 5 more files in changeset.
Move fixtures from `:ide` into a separate package

    • -0
    • +214
    ./groovy/org/gradle/plugins/ide/fixtures/IdeaModuleFixture.groovy
    • -0
    • +53
    ./groovy/org/gradle/plugins/ide/fixtures/IdeaProjectFixture.groovy
  1. … 7 more files in changeset.
Integration test coverage for IDEA metadata generation in composite build

- This test simply adds coverage for existing capabilities

  1. … 2 more files in changeset.
Add more coverage for Play/IDEA plugin

  1. … 2 more files in changeset.
Add integration coverage for using Play with IDEA

- Extract test fixtures from :ide for use in :idePlay

- Verify that all Play sources are sourceFolders

- Verify that Java version and Scala version match PlayPlatform

    • -0
    • +33
    ./groovy/org/gradle/plugins/ide/idea/IdeaFixtures.groovy
  1. … 13 more files in changeset.