[
https://issues.apache.org/jira/browse/GROOVY-11715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Paul King updated GROOVY-11715:
-------------------------------
Description:
We have fixed a few previous issues. This is the last remaining one that we
know of. The symptoms are that on subsequent builds of the Grails project, the
order in which annotation attributes are written into the bytecode varies, e.g.:
{code:groovy}
public void render(@groovy.lang.DelegatesTo(
strategy = 1,
type = "",
value = groovy.lang.DelegatesTo.Target.class,
target = "",
genericTypeIndex = -1) groovy.lang.Closure closure) { /* compiled code */ }
{code}
vs
{code:groovy}
public void render(@groovy.lang.DelegatesTo(
strategy = 1,
genericTypeIndex = -1,
type = "",
value = groovy.lang.DelegatesTo.Target.class,
target = "") groovy.lang.Closure closure) { /* compiled code */ }
{code}
While these are logically equivalent, the arbitrary ordering hinders
reproducibility.
Unlike the previous cases where we understood where the non-determinism was
probably coming from, here we haven't tracked down the root cause.
Never-the-less, it seems worth tackling the symptoms for now and we can always
back out the current changes if we can find a more direct fix.
was:
We have fixed a few previous issues. This is the last remaining one that we
know of. The symptoms are that on subsequent builds of the Grails project, the
order in which annotation attributes are written into the bytecode varies, e.g.:
{code:groovy}
public void render(@groovy.lang.DelegatesTo(
strategy = 1,
type = "",
value = groovy.lang.DelegatesTo.Target.class,
target = "",
genericTypeIndex = -1) groovy.lang.Closure closure) { /* compiled code */ }
{code}
vs
{code:groovy}
public void render(@groovy.lang.DelegatesTo(
strategy = 1,
genericTypeIndex = -1,
type = "",
value = groovy.lang.DelegatesTo.Target.class,
target = "") groovy.lang.Closure closure) { /* compiled code */ }
{code}
While these are logically equivalent, they hinder reproducibility.
Unlike the previous cases where we understood where the non-determinism was
probably coming from, here we haven't tracked down the root cause.
Never-the-less, it seems worth tackling the symptoms for now and we can always
back out the current changes if we can find a more direct fix.
> Grails reproducible build part 3: DelegatesTo ordering
> ------------------------------------------------------
>
> Key: GROOVY-11715
> URL: https://issues.apache.org/jira/browse/GROOVY-11715
> Project: Groovy
> Issue Type: Bug
> Reporter: Paul King
> Priority: Major
>
> We have fixed a few previous issues. This is the last remaining one that we
> know of. The symptoms are that on subsequent builds of the Grails project,
> the order in which annotation attributes are written into the bytecode
> varies, e.g.:
> {code:groovy}
> public void render(@groovy.lang.DelegatesTo(
> strategy = 1,
> type = "",
> value = groovy.lang.DelegatesTo.Target.class,
> target = "",
> genericTypeIndex = -1) groovy.lang.Closure closure) { /* compiled code */
> }
> {code}
> vs
> {code:groovy}
> public void render(@groovy.lang.DelegatesTo(
> strategy = 1,
> genericTypeIndex = -1,
> type = "",
> value = groovy.lang.DelegatesTo.Target.class,
> target = "") groovy.lang.Closure closure) { /* compiled code */ }
> {code}
> While these are logically equivalent, the arbitrary ordering hinders
> reproducibility.
> Unlike the previous cases where we understood where the non-determinism was
> probably coming from, here we haven't tracked down the root cause.
> Never-the-less, it seems worth tackling the symptoms for now and we can
> always back out the current changes if we can find a more direct fix.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
