[
https://issues.apache.org/jira/browse/GROOVY-11806?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18039935#comment-18039935
]
Eric Milles commented on GROOVY-11806:
--------------------------------------
Based on the layout of your project, it looks like you do not include the java
source folder as part of the stub generation step. The joint compiler
leverages knowledge of the java sources to do some type resolution. Without
the java sources, the "import io.restassured.specification.*" is not enough to
resolve "ResponseSpecification".
Groovy 5 tried to remove the imports since resolved types are written
fully-qualified. We did not have any cases where the imports were still
required, so they were dropped from the stubs.
> Groovy 5: joint compilation generates stubs without imports for implemented
> interfaces in other packages (works in 4.x)
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: GROOVY-11806
> URL: https://issues.apache.org/jira/browse/GROOVY-11806
> Project: Groovy
> Issue Type: Bug
> Components: Compiler, Stub generator / Joint compiler
> Affects Versions: 5.0.2
> Reporter: Johan Haleby
> Assignee: Eric Milles
> Priority: Major
>
> Joint compilation with Groovy 5.x generates invalid Java stubs for Groovy
> classes that implement interfaces located in a different package. The
> generated stubs are missing imports for those interfaces and other referenced
> types, which causes javac to fail with cannot find symbol errors.
> The same project works correctly with Groovy 4.0.x. You can try it out
> yourselves by doing this:
> {code:java}
> $ git clone [email protected]:rest-assured/rest-assured.git
> $ cd rest-assured
> $ git checkout java17-groovy5
> $ mvn clean install{code}
> h5.
> h5.
> Environment
> * Groovy: 5.0.2
> * Previously worked with 4.0.x
> * JDK: 17
> * Build tool: Maven
> * Groovy integration: org.codehaus.gmavenplus:gmavenplus-plugin
> Maven gmavenplus configuration:
>
> {code:java}
> <plugin>
> <groupId>org.codehaus.gmavenplus</groupId>
> <artifactId>gmavenplus-plugin</artifactId>
> <version>4.2.1</version>
> <dependencies>
> <dependency>
> <groupId>org.apache.groovy</groupId>
> <artifactId>groovy</artifactId>
> <version>5.0.2</version>
> </dependency>
> </dependencies>
> <executions>
> <execution>
> <goals>
> <goal>addSources</goal>
> <goal>addTestSources</goal>
> <goal>generateStubs</goal>
> <goal>compile</goal>
> <goal>generateTestStubs</goal>
> <goal>compileTests</goal>
> <goal>removeStubs</goal>
> <goal>removeTestStubs</goal>
> </goals>
> </execution>
> </executions>
> </plugin>
>
> {code}
>
> h5. Simplified problem description
> * There is a Java interface ResponseSpecification in package
> io.restassured.specification.
> * There is a Groovy class ResponseSpecificationImpl in package
> io.restassured.internal that implements FilterableResponseSpecification and
> ResponseSpecification, and uses other types from different packages
> (Argument, ResponseLogSpecification, etc.).
> * With Groovy 4.0.x, gmavenplus’ generateStubs goal creates valid Java stubs
> for ResponseSpecificationImpl, including correct import statements for all
> referenced types.
> * With Groovy 5.x, the generated stub no longer contains those imports,
> leaving only the simple names. As a result, javac cannot resolve them in the
> io.restassured.internal package and compilation fails.
>
> h5. Example of broken stub (Groovy 5.x)
>
> The generated stub for io.restassured.internal.ResponseSpecificationImpl
> looks like this (excerpt):
>
> {code:java}
> package io.restassured.internal;
> import static io.restassured.http.ContentType.ANY;
> public class ResponseSpecificationImpl
> extends java.lang.Object implements
> FilterableResponseSpecification, groovy.lang.GroovyObject {
> public ResponseSpecificationImpl(String bodyRootPath,
> ResponseSpecification defaultSpec,
> ResponseParserRegistrar rpr,
> io.restassured.config.RestAssuredConfig
> config,
> io.restassured.internal.log.LogRepository
> logRepository) {
> super();
> }
> public ResponseSpecification body(java.util.List<Argument> arguments,
> org.hamcrest.Matcher matcher,
> Object... additionalKeyMatcherPairs) {
> return null; }
> public ResponseSpecification body(String key,
> org.hamcrest.Matcher matcher,
> Object... additionalKeyMatcherPairs) {
> return null; }
> public ResponseLogSpecification log() { return null; }
> public RequestSpecification given() { return null; }
> public ResponseSpecification response() { return null; }
> // ... many other methods referencing ResponseSpecification, Argument,
> // ResponseLogSpecification, RequestSpecification, etc.
> }
> {code}
>
> * FilterableResponseSpecification and ResponseSpecification are simple names
> with no import.
> * Argument, ResponseLogSpecification, RequestSpecification, etc. also appear
> as simple names with no imports.
> * These types actually live in other packages (io.restassured.specification,
> io.restassured.internal.path, …), so from javac’s perspective in package
> io.restassured.internal; they cannot be resolved.
> This leads to errors such as:
>
> {code:java}
> target/generated-sources/groovy-stubs/main/io/restassured/internal/ResponseSpecificationImpl.java:[6,5]
> cannot find symbol
> symbol: class FilterableResponseSpecification
> ...
> target/generated-sources/groovy-stubs/main/io/restassured/internal/ResponseSpecificationImpl.java:[20,51]
> cannot find symbol
> symbol: class Argument{code}
>
>
> h5. Expected behavior
> * Groovy 5.x should generate Java stubs equivalent to Groovy 4.x for joint
> compilation:
> ** All referenced types from other packages should be fully resolvable by
> javac, typically via generated import statements or fully qualified names.
>
> * The Maven build using gmavenplus + maven-compiler-plugin should succeed
> with Groovy 5.x just as it does with Groovy 4.x.
> h5. *Actual behavior*
> * With Groovy 5.x, the stub for a Groovy class implementing interfaces in
> another package is missing necessary imports.
> * maven-compiler-plugin (javac) fails on the generated stub with cannot find
> symbol errors for those interfaces and other referenced types.
> * Downgrading only the Groovy version back to 4.0.x (keeping the rest of the
> Maven configuration identical) makes the problem disappear.
> h3. Notes
> * This looks like a regression in Groovy 5’s stub generation / joint
> compilation compared to Groovy 4.
> * The plugin (gmavenplus) is just invoking Groovy’s stub generator; it does
> not manipulate the contents of the stubs.
> * I can provide a minimal reproducer Maven project (one Java interface in
> package A, one Groovy implementation in package B, joint compilation via
> gmavenplus) if needed.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
