Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fix missing Groovy/Scala classes in runtime variant

By using the infrastructure built in `JvmPluginsHelper` we

can now make sure that the languages we support expose their

classes on the "classes" variant.

    • -8
    • +12
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
  1. … 4 more files in changeset.
Add test showing consuming a Groovy library may be broken

The Java library, as well as the Java library plugins define

a "classes" variant, that is "for runtime" use. There is, currently,

no code that would explicitly require this variant. However, if, and

only if, a configuration is wired to do so, then Groovy classes

become "invisible" to the consumer.

This is similar to #7398 and #8788 but for "runtime" use. This didn't

surface as a problem because for runtime we always ask for jars, so

the test is here to prove that if we ask for a more specific variant

then we have the problem.

    • -9
    • +88
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
Add test showing consuming a Groovy library may be broken

The Java library, as well as the Java library plugins define

a "classes" variant, that is "for runtime" use. There is, currently,

no code that would explicitly require this variant. However, if, and

only if, a configuration is wired to do so, then Groovy classes

become "invisible" to the consumer.

This is similar to #7398 and #8788 but for "runtime" use. This didn't

surface as a problem because for runtime we always ask for jars, so

the test is here to prove that if we ask for a more specific variant

then we have the problem.

    • -9
    • +88
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
Add test showing consuming a Groovy library may be broken

The Java library, as well as the Java library plugins define

a "classes" variant, that is "for runtime" use. There is, currently,

no code that would explicitly require this variant. However, if, and

only if, a configuration is wired to do so, then Groovy classes

become "invisible" to the consumer.

This is similar to #7398 and #8788 but for "runtime" use. This didn't

surface as a problem because for runtime we always ask for jars, so

the test is here to prove that if we ask for a more specific variant

then we have the problem.

    • -9
    • +88
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
Add test showing consuming a Groovy library may be broken

The Java library, as well as the Java library plugins define

a "classes" variant, that is "for runtime" use. There is, currently,

no code that would explicitly require this variant. However, if, and

only if, a configuration is wired to do so, then Groovy classes

become "invisible" to the consumer.

This is similar to #7398 and #8788 but for "runtime" use. This didn't

surface as a problem because for runtime we always ask for jars, so

the test is here to prove that if we ask for a more specific variant

then we have the problem.

    • -9
    • +88
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
Add test showing consuming a Groovy library may be broken

The Java library, as well as the Java library plugins define

a "classes" variant, that is "for runtime" use. There is, currently,

no code that would explicitly require this variant. However, if, and

only if, a configuration is wired to do so, then Groovy classes

become "invisible" to the consumer.

This is similar to #7398 and #8788 but for "runtime" use. This didn't

surface as a problem because for runtime we always ask for jars, so

the test is here to prove that if we ask for a more specific variant

then we have the problem.

    • -9
    • +88
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
Add test showing consuming a Groovy library may be broken

The Java library, as well as the Java library plugins define

a "classes" variant, that is "for runtime" use. There is, currently,

no code that would explicitly require this variant. However, if, and

only if, a configuration is wired to do so, then Groovy classes

become "invisible" to the consumer.

This is similar to #7398 and #8788 but for "runtime" use. This didn't

surface as a problem because for runtime we always ask for jars, so

the test is here to prove that if we ask for a more specific variant

then we have the problem.

    • -9
    • +88
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
Add test showing consuming a Groovy library may be broken

The Java library, as well as the Java library plugins define

a "classes" variant, that is "for runtime" use. There is, currently,

no code that would explicitly require this variant. However, if, and

only if, a configuration is wired to do so, then Groovy classes

become "invisible" to the consumer.

This is similar to #7398 and #8788 but for "runtime" use. This didn't

surface as a problem because for runtime we always ask for jars, so

the test is here to prove that if we ask for a more specific variant

then we have the problem.

    • -9
    • +88
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
Add test showing consuming a Groovy library may be broken

The Java library, as well as the Java library plugins define

a "classes" variant, that is "for runtime" use. There is, currently,

no code that would explicitly require this variant. However, if, and

only if, a configuration is wired to do so, then Groovy classes

become "invisible" to the consumer.

This is similar to #7398 and #8788 but for "runtime" use. This didn't

surface as a problem because for runtime we always ask for jars, so

the test is here to prove that if we ask for a more specific variant

then we have the problem.

    • -9
    • +88
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

    • -27
    • +12
    ./GroovyLibraryIntegrationTest.groovy
  1. … 3 more files in changeset.
Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

    • -27
    • +12
    ./GroovyLibraryIntegrationTest.groovy
  1. … 3 more files in changeset.
Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

    • -27
    • +12
    ./GroovyLibraryIntegrationTest.groovy
  1. … 3 more files in changeset.
Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

    • -27
    • +12
    ./GroovyLibraryIntegrationTest.groovy
  1. … 3 more files in changeset.
Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

    • -27
    • +12
    ./GroovyLibraryIntegrationTest.groovy
  1. … 3 more files in changeset.
Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

    • -27
    • +12
    ./GroovyLibraryIntegrationTest.groovy
  1. … 3 more files in changeset.
Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

    • -27
    • +12
    ./GroovyLibraryIntegrationTest.groovy
  1. … 3 more files in changeset.
Fix compilation of Groovy projects depending on a library

This commit introduces a new "library elements" type corresponding

to the classes AND resources of a library. Groovy projects now tell

that they needs both the classes and resources (because the Groovy

compiler requires some descriptors).

Currently the implementation is basic as it will fallback to a jar

thanks to the attribute compatibility rules. However, it would be

better to provide a variant which actually packages only the classes

and resources as directories instead of within a jar.

Fixes #9872

    • -27
    • +12
    ./GroovyLibraryIntegrationTest.groovy
  1. … 3 more files in changeset.
Full recompilation with annotation processor

    • -3
    • +48
    ./compile/BasicGroovyCompilerIntegrationSpec.groovy
  1. … 2 more files in changeset.
Full recompilation with annotation processor

    • -2
    • +45
    ./compile/BasicGroovyCompilerIntegrationSpec.groovy
  1. … 1 more file in changeset.
Full recompilation with annotation processor

    • -3
    • +48
    ./compile/BasicGroovyCompilerIntegrationSpec.groovy
  1. … 2 more files in changeset.
Full recompilation with annotation processor

    • -3
    • +48
    ./compile/BasicGroovyCompilerIntegrationSpec.groovy
  1. … 2 more files in changeset.
Add test case for #9872

    • -0
    • +107
    ./GroovyLibraryIntegrationTest.groovy
WIP

    • -1
    • +1
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
  1. … 46 more files in changeset.
Rename format attribute and clean up values

Attribute is now org.gradle.libraryelements and only applied

to variants having the org.gradle.category at library.

This means that values related to platforms or document in the

former format attribute are removed.

    • -1
    • +1
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
  1. … 46 more files in changeset.
Rename format attribute and clean up values

Attribute is now org.gradle.libraryElements and only applied

to variants having the org.gradle.category at library.

This means that values related to platforms or document in the

former format attribute are removed.

    • -1
    • +1
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
  1. … 46 more files in changeset.
Rename format attribute and clean up values

Attribute is now org.gradle.libraryelements and only applied

to variants having the org.gradle.category at library.

This means that values related to platforms or document in the

former format attribute are removed.

    • -1
    • +1
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
  1. … 46 more files in changeset.
Rename format attribute and clean up values

Attribute is now org.gradle.libraryElements and only applied

to variants having the org.gradle.category at library.

This means that values related to platforms or document in the

former format attribute are removed.

    • -1
    • +1
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
  1. … 46 more files in changeset.
Rename format attribute and clean up values

Attribute is now org.gradle.libraryElements and only applied

to variants having the org.gradle.category at library.

This means that values related to platforms or document in the

former format attribute are removed.

    • -1
    • +1
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
  1. … 46 more files in changeset.
Rename format attribute and clean up values

Attribute is now org.gradle.libraryelements and only applied

to variants having the org.gradle.category at library.

This means that values related to platforms or document in the

former format attribute are removed.

    • -1
    • +1
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
  1. … 46 more files in changeset.
Rename format attribute and clean up values

Attribute is now org.gradle.libraryElements and only applied

to variants having the org.gradle.category at library.

This means that values related to platforms or document in the

former format attribute are removed.

    • -1
    • +1
    ./GroovyJavaLibraryInteractionIntegrationTest.groovy
  1. … 46 more files in changeset.