https://grails.org/ logo
Join Slack
Powered by
If people here were wanting to upgrade a reasonabl...
# questions
j
If people here were wanting to upgrade a reasonably simple application from Grails 5 to Grails 7, would you: a) Upgrade the version numbers etc in situ, correct any breaking changes, etc., or b) Create a new Grails 7 app from the application forge and move the domain classes, controllers, services, views, etc., across? I know it's hard to say, but in my experience there's a level of change between versions which makes the second option the easier one and I was just wondering whether 5 to 7 was such a one. (By contrast, 4 to 5 was a doddle to do in situ, at least on the 3 or 4 apps I tried).
j
how about c) ...
j
Depends...
j
i don't think the libraries changed that significantly between 6 & 5. Assuming thats' true, you can use this https://github.com/apache/grails-core/blob/7.0.x/etc/bin/rename_gradle_artifacts.sh to mass convert all of the dependency names
šŸ‘ 1
g
I always moved Grails version with option B
j
https://docs.grails.org/latest/guide/upgrading.html#upgrading60x has a lot of infomration outside of just comparing versions
generating a 5.x app, and then a 7.x app and comparing is usually how i find out what needs made
but that's a LOT harder in 7, b/c of the renames
that's why that script exists
it will do 90% of the gradle work for you
I will say this if you use plugins, they must be updated - it will block your upgrade otherwise.
i think updating the gradle files is the easy part in 7 ... it's all of the impacts of groovy 4 + jakarta + deprecation removals , etc
j
That's handy, thanks. I think I'll probably go with b) for now on one app and see how it goes. Dipping my toe into v7 for the first time!
j
the m5 should be almost release candidate worthy. It was the first milestone where we fixed every test that was broken in 7 ... and even fixes tests that broke in 6
there are some subsquenet fixes around the CLIs, etc but it's all minor
j
Presumably available via SDKMan, and in Application Forge?
j
yes
they're both there, if you have any issues feel free to reach out here or the user mailing list
I don't think any ofthe found issues will impact you, but if they do I have workarounds for alot of it
j
Super stuff!
p
What I usually do is I create an app with the new version of grails then I compare dependencies, version numbers, etc. and I start updating my app in a new branch with those new dependencies. I also check the migration guides just in case there is some grails class that was actually modified (change on name or package) or deprecated and a new one is proposed as a replacement (checking compatibility with the class API, etc). I know it's a poor mans process, but at least I know every single step I needed to do to make things work, so I can replicate it to other apps.
j
Generating a v6 app, then running that rename script & comparing that result to a 7 project will probably make it easier
p
I was talking in general, because I generally skip the even versions :)
j
Is there some resource which tells me which plugins are Grails 7 compliant and which are not (yet)? Or do I have to go to the page of each one and look at the release notes?
j
we hae a ticket to add a plugin bom for this exact purpose, but we haven't gotten around to it yet ... so each plugin page =/
you should be able to open the plugin class and check the version or history of that class to really know
j
Thx. There are a couple of apps I was planning to move which use plugins which haven't been updated for a while (like the Shiro plugin), so I may have to hold off for a while, or rewrite them not to use Shiro.
j
do you have a link to the source for shiro?
j
The plugin, you mean (as opposed to the Java library)? https://github.com/nerdErg/grails-shiro
j
yes
so looking at the pom files for shiro, I see this:
``` <groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<version>4.0.1</version>
<scope>provided</scope>```
One of the major changes with Grails 7 is we've moved on to jakarta. It seems Shiro itself hasn't updated to jakarata (https://github.com/apache/shiro/issues/1585) There are work arounds to get it to work but it depends how javax is being used.
It does look like they have the shade plugin ... so maybe it's possible to use then
@Peter McNeil do you plan to update this plugin? It seems you were one of the last people to update it.
@John Moore I don't mind making a pass at updating that plugin, but will wait for @Peter McNeilā€™s response before doing so.
j
Wow, thanks! I would have thought you had plenty on your plate as it was! šŸ™‚
j
Plugin updates take about 20-30 min typically now. As long as the underlying library can support our versions. If it can't support the latest versions, then obviously , I would circle back.
I've also been making a push to have less Grails dependencies in our pom files, so going forward it's less likely to break unless there's an API change.
I'll give Peter a day to respond. If he doesn't will reach out in email to get his thoughts.
j
If there's any difficulty whatsoever, then don't spend any more time on it, as I've been toying with the idea of moving to Spring Security anyway as that's the canonical security solution, and I'm not sure how many people out there are using Shiro these days.
j
we actually brought up supporting shiro initially on the mailing list when we came to the ASF. I know there are people that use the plugin so I'm incentivized to help with an initial update
j
Great!
j
I'm also happy to show you how to update it, we could always use more contributors šŸ˜ƒ
(even if that's a pair programming session)
4 Views
Open in Slack
PreviousNext
Powered by