This message was deleted.
# questions
s
This message was deleted.
m
Thanks, @robertjstroud. But, the question is then, more specifically, what incompatibility? Is it still in play? 6.1.0 starter apps work without it. Is it justified to have it in every newly created Grails 6.1.x app? It was added in this commit, but there is no explanation. Maybe @puneetbehl remembers?
r
The incompatibility could be quite obscure, so the fact that 6.1.0 starter apps seem to work without it doesn't mean that the problem has gone away. I agree it would be good to know why it's there and what needs to be fixed before it can be removed.
I found a bug in my legacy application the other day in a workaround for an unspecified Grails bug that was probably fixed long ago - the surprising thing was that the bug in the workaround hadn't appeared sooner. I suspect there were two bugs - the original Grails bug, and some undocumented / unintended behaviour that masked the bug in the workaround but was fixed when I upgraded, thereby exposing the bug in the workaround.
s
I know that the groovy xml module changed the base pacakge namepsace for all the xml classes. It might be to do with that.
m
@Steve Osguthorpe Yes maybe, but to my understanding the old packages are only deprecated in Groovy 3 and not removed until Groovy 4. And such changes should not effect patch releases anyway.
r
Indeed - that was my understanding too. The Groovy namespace doesn't moves from
org.codehaus.groovy
to
org.apache.groovy
until Groovy 4. Perhaps the intention was to force the build to use a 3.0.x version of groovy-xml rather than a 4.0.x version, although at the time of the commit, the most recent 3.0.x version of groovy-xml was 3.0.16.
m
Thanks for the input, let's see if Puneet (or anyone else) weighs in and brings some clarity 😄