Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Resolve feedback

    • -18
    • +6
    ./compile/BasicGroovyCompilerIntegrationSpec.groovy
  1. … 1 more file in changeset.
Resolve feedback

    • -18
    • +6
    ./compile/BasicGroovyCompilerIntegrationSpec.groovy
  1. … 1 more file in changeset.
Refine deprecation warning

    • -32
    • +18
    ./compile/BasicGroovyCompilerIntegrationSpec.groovy
  1. … 3 more files in changeset.
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.
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.
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.
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.
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.
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.
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.
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.