Grails 6 - Groovy 3.x and Asset Pipeline Plugin Out of Date

[codeconsole]

Expected Behavior

Would expect a new major version to at least have the latest patch releases.

1. Why is grails 6.0.0 with Groovy 3.0.11 when 3.0.17 is out?
2. Asset pipeline should be the latest. com.bertramlabs.plugins:asset-pipeline-grails:4.3.0
3. If the whole motivation behind 6.0.0 is to depend on gradlew for running, why not at least use the latest version of gradle? 8.1.1 Anything less is disappointing.

https://mvnrepository.com/artifact/org.codehaus.groovy/groovy/3.0.11

Actual Behaviour

Groovy version: 3.0.11
com.bertramlabs.plugins:asset-pipeline-grails:3.4.7

Steps To Reproduce

grails create-app website
./gradlew bootRun

Environment Information

No response

Example Application

No response

Version

6.0.0-RC1

[codeconsole]

[olavgg]

Agreed, I think these small bumps should be in place.

[puneetbehl]

Why is grails 6.0.0 with Groovy 3.0.11 when 3.0.17 is out?

There are some challenges updating to support Apache Groovy 3.0.17 which may require another patch release of Groovy. So, I think we should not hold the release before we can support latest Groovy patch.

Asset pipeline should be the latest. com.bertramlabs.plugins:asset-pipeline-grails:4.3.0

I'll try to update this if there are no major changes required.

If the whole motivation behind 6.0.0 is to depend on gradlew for running, why not at least use the latest version of gradle? 8.1.1 Anything less is disappointing.

I am sorry that you feel disappointed but I believe motivation behind 6.0.0 is not about using Gradle for running.

There are a lot of factors including timelines which contributes to selecting dependency versions. I feel with Grails we are always trying to catch-up with the latest releases of underline libraries so it is tough for us to include latest version of all of them.

[codeconsole]

@puneetbehl thanks for the reply

Why is grails 6.0.0 with Groovy 3.0.11 when 3.0.17 is out?

There are some challenges updating to support Apache Groovy 3.0.17 which may require another patch release of Groovy. So, I think we should not hold the release before we can support latest Groovy patch.

Is there a reference to an open Groovy ticket regarding what is required to upgrade to 3.0.17? It's just strange using a version of Groovy that is 6 releases prior especially when the release cycle for Groovy is so slow.

[puneetbehl]

I must admit that I currently lack the specific reference, but I vaguely recall encountering some challenges while attempting to support the latest Apache Groovy patch. I would like to mention that updating the Apache Groovy version in Grails Core isn't as straightforward as it may seem, as it necessitates updating and thoroughly testing various other projects like GORM, GSP, Views, Testing Support, and more.

As I mentioned earlier, our team is mindful not to delay the release of Grails 6 due to this update. Instead, we are considering incorporating the latest Apache Groovy patch in a Grails Minor release. Furthermore, I'd like to kindly bring to your attention that if you have any compelling reasons to update to Apache Groovy 3.0.18, you have the option to do so by defining a property groovyVersion=3.0.18 in the gradle.properties file.

At our end, we always strive to support the latest available version of Apache Groovy to provide the best experience to our users. However, I must admit that there are times when it becomes challenging due to various complexities and dependencies involved. Despite these challenges, we are committed to making continuous improvements and doing our best to support the latest versions whenever possible. Your understanding and support are greatly appreciated in this endeavor. If anyone from the community would like to contribute to this effort or assist in any way, we would be immensely grateful for your involvement. Working together, we can overcome challenges and enhance the overall Grails experience for everyone.

[codeconsole]

@puneetbehl I don't mind contributing. My concern is if there was an outstanding issue that could affect Gails running properly using a latest version of Groovy. It would have also been useful to know what the outstanding issues were so that I could propose a fix. I know that in the past there have been breaking changes in upgrading Groovy, but I was able to work with the Groovy team to get those resolved in an expedited manner.

I have already put considerable time getting SiteMesh up to date and am waiting on 2 pull requests to be merged:
grails/grails-gsp#362
grails/grails-gsp#364

I am more than happy to continue contributing once those have been merged. I suppose a fear with contributing is always spending a considerable time working on something and not seeing the your pull request merged. I am sure that this is not the case as I have yet to experience that here, but I will hold off on investing more time until I do see those requests merged.

[puneetbehl]

We greatly appreciate your contribution. I want to assure you that I will do my utmost to thoroughly review and incorporate the pull requests. As of now, I've released Grails GSP 6.0.1, which integrates your modifications.

In regard to the upgrade of Apache Groovy, I don't recall any open issues references. I think you can begin by reviewing, updating, or creating pull requests that involve updating Groovy to version 3.0.18. This update should be applied to various repositories including grails/grails-gsp, grails/grails-data-mapping, grails/grails-testing-support, grails/grails-core, grails/grails-views, grails/gorm-hibernate5, grails/gorm-mongodb, grails/gorm-neo4j, and grails/grails-functional-tests. I'd like to emphasize that our goal is not only to address the issue but also to assess the potential impact of these changes on Grails applications while ensuring compatibility with semantic versioning principles.

[codeconsole]

@puneetbehl I still have some pull requests that need merged:
grails/grails-gsp#367
grails/grails-gsp#366
grails/grails-doc#861

[codeconsole]

@puneetbehl
Pull request #13118

[codeconsole]

@puneetbehl Can I get commit/push permissions direct to https://github.com/grails/grails-boot
I am almost done overhauling it. No need to bother you every time I want to commit to it.

[codeconsole]

@puneetbehl I've got a pull request for grails-boot
Since grails-boot has been long since abandoned, I was wondering if I could get write access direct to the repo? I already have a working prototype for Grails 6, but I would like to make branches according to what version of Grails it works with.

[rainboyan]

@codeconsole In my opinion, this repository should be merged into grails-gsp, and most of the Grails plugins can be replaced by Spring Boot's AutoConfiguration, I've already done this in GoBoots, it proved to be feasible and has many benefits.

[codeconsole]

@rainboyan it's just 1 auto configuration file and 2 example apps. Since I have already done the work, I'd like to get it updated and cleaned up. I think it belongs separate for now as grails-gsp is still pretty coupled to Grails.

I've already got grails-boot working with Grails 6 and SiteMesh2 or SiteMesh3

[rainboyan]

I know what you mean, this might be an easy option to get things running and then find something else. Indeed, with the current Grails architecture, it's hard to change much, and it takes courage and determination.
I haven't had time to dive into supporting SiteMesh 2 and SiteMesh 3, but I think it's better to use AutoConfiguration instead of introducing new plugins, which is the way Spring Boot recommends.

The biggest problem with Grails today is that it doesn't use the Spring way, it seems to be built on Spring Boot, but it's not, and even with Spring Boot experience, it's hard to understand. In addition, the introduction of Micronaut did improve performance, but it did not change its essence, did not bring more benefits, but increased complexity. I've removed Micronaut in GoBoots and it works fine.

[codeconsole]

@rainboyan I still don't quite understand GoBoots? The repository on your profile just points to a forked Grails with not active branches. I also don't see any documentation anywhere.

SiteMesh3 has an AutoConfiguration available and the Grails SiteMesh 3 Plugin uses it.

I already have my copy of grails-boot using SiteMesh 3, but I am still waiting on @puneetbehl to merge my first pull request grails/grails-boot#6 and hopefully just give me access to grails-boot repository since it is dead and already I completely overhauled it.

[rainboyan]

@codeconsole You can implement it as you think, and later when you publish the code, I can submit a PR based on the results you've done and combine it with one of the ways I just said.

Here are a few prerequisites,

• SiteMesh 2 is decoupled from Grails, it looks like you're done, but I think it may need to be abstracted appropriately and provide some interface.
• SiteMesh 3 offers Spring Boot Starter, and you already have done
• Grails GroovyPagesGrailsPlugin need to use AutoConfiguration instead and I've done that

After completing the above, some of them need to be adjusted and tested.

[codeconsole]

@puneetbehl

1. Can you please create a grails 7.x branch on grails-core and grails-gsp in case I decide to get adventurous and start working on jakarta?

2. Are you able to give me direct commit access to grails-boot?

Waiting on Pull Requests:
#13136
grails/grails-boot#6

[rainboyan]

Contributing is hard.
A lot of issues are put on hold, no one responds, a lot of time is waiting for code review and merge, we need a new collaborator, although the project currently requires contributors to submit code, but it is more important to need one person to communicate, coordinate, review, and merge code.

@codeconsole Are you interested? I vote for you, if I have one.：）

[codeconsole]

@rainboyan I just want to see Groovy 4 + JDK 17 + Spring Boot 3 + SiteMesh 3 + Jakarta as soon as possible so I'm willing to help out in any way I can to expedite that. I think @puneetbehl is doing a good job managing the releases, but we definitely need more movement on contributions.

[rainboyan]

@codeconsole Yes, I understand your feelings very well.

If you want to use Groovy 4, there's no need to wait until Grails 7, I'm sure Grails 5 will do. However, they did not do so and have not yet upgraded to the latest version of Groovy 3.
If you want to use SiteMesh 3, there's no need to wait until Grails 7, I've seen some work you've done to get there, and indeed, it's time for Grails' internal API design to be refactored, and I'm wondering why the development team isn't interested in needing to refactor? Too many legacy design issues that should be addressed as early as possible.
As for Spring Boot 3 + Jakarta, I think we've been waiting for this for too long to see a roadmap for Grails 7. This can cause all users to lose confidence and even cause panic about whether Grails is dead.

I did all of the above in GoBoots and spent a lot of time refactoring the entire framework. Now, instead of caring about Spring Boot 3 and Groovy 4, I'm starting to think about the core principles and design ideas of Grails, how to make Grails different, how to keep Grails on its own and follow trends, and how to make developers happy, because we are all end users.

We want Grails to get better, I think the owner behind Grails need to find investment, get more support from other companies, and grow their development teams. Being acquired, or donated to Apache, makes it more open, transparent, and regulated.