[ 
https://issues.apache.org/jira/browse/GROOVY-11954?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul King reassigned GROOVY-11954:
----------------------------------

    Assignee: Paul King

> groovydoc: short-name type resolution cache makes doc output order-dependent 
> and non-reproducible
> -------------------------------------------------------------------------------------------------
>
>                 Key: GROOVY-11954
>                 URL: https://issues.apache.org/jira/browse/GROOVY-11954
>             Project: Groovy
>          Issue Type: Bug
>          Components: groovy-groovydoc
>            Reporter: Mattias Reichel
>            Assignee: Paul King
>            Priority: Minor
>
> There are reproducibility problems for javadoc jars in the Grails project. 
> Some of these issues have been fixed previously Groovy 4. However this issue 
> still lingers when I verify Grails releases and I have seen that at least 
> some of the problems are that {{java.util.Date}} and {{java.sql.Date}} are 
> ordered differently across different builds.
> Problem description below generated with the help of GPT-5.4. It has also 
> generated tests and a fix that can be put in a PR if desired.
> {{groovy-groovydoc}} can produce non-reproducible output when resolving 
> ambiguous short type names such as {{{}Date{}}}.
> h3. Problem
> During Groovydoc generation, short type names are resolved in a 
> class-specific context using that class’s imports, aliases, package, and 
> nested types.
> However, {{SimpleGroovyClassDoc.resolveClass(...)}} uses the root-level cache 
> from {{SimpleGroovyRootDoc.getResolvedClasses()}} keyed only by the requested 
> name.
> This is incorrect for short names like {{{}Date{}}}, because the same short 
> name may resolve differently in different classes, e.g.:
>  * {{java.util.Date}}
>  * {{java.sql.Date}}
> As a result, whichever class resolves Date first can populate the shared 
> cache and affect later resolutions in other classes. This makes the generated 
> documentation depend on source processing order and can lead to 
> non-reproducible Javadoc/Groovydoc JARs.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Reply via email to