Hi Scott,
Comments inline:
* Rapid fix is feasible
How is this rapid fix feasible? Currently the following are broken:
1. nested layouts (where you don't know the layouts up front)
2. async actions
3. ${raw()} in titles
4. layout specified by controller property
5. layout by convention
6. forwarding in a controller
The forwarding issue may be rapidly fixable, but the reason we're reverting
isn't just that reason, it's all of these problems. You have previously
stated you aren't sure how layout by convention would work. Do you have
any idea how to implement this now? Do you have an idea how to dynamically
determine layouts so you don't have to nest them upfront in a meta tag?
These are hard problems that aren't quick to fix.
* Risk of a major functional regression
The regressions are why we are reverting. We would be no different than
Grails 6.
* Breaking the 7.x eco system
If I understand correctly, "breaking" means it's coupled to grails specific
sitemesh 2 classes and removing sitemesh 2 will then cause those plugins to
fail? We can mock out those classes when we later upgrade or add
abstractions to reduce that dependence.
* Obsolete, unmaintained code
We can fork it to maintain it then. This proposal is only to go back to
2.x, with the initial work being 2.6. Grails 6 is on 2.4.4 so this is
still an upgrade. We are open to jumping to the latest 2.7 version if
contributions materialize. Can you point to a specific CVE in this branch?
It looks like these are the differences:
https://github.com/sitemesh/sitemesh2/compare/2.6.x...2.7.0-M1
* Licensing
We've already acknowledged we would double check with ASF legal, but the
license is a derivative of the ASF license. It even states it's compatible
with ASF 2.0 code and Struts is currently using sitemesh 2 so there's
precedence for the license not being an issue.
* Unrealistic test coverage
The reason we're reverting is because of the scope of current test
breakage. There were numerous tests fixed by reverting and the community
has reported numerous issues with it.
* Wrong 2.x code line.
Other frameworks are using 2.6 and we are only reverting from sitemesh3.
We can go to 2.7 if you think you can help us.
* Opportunity Cost
The cost has already occurred. We've waited 8 months for these issues to be
fixed and they have not been. We are a volunteer organization and the
volunteers are saying it's worth going back. Especially those of us who
have actively contributed for the last few months.
Overall, I strongly disagree with your assessment. We are not
permanently reverting to 2.x. We are only reverting to it so we can
release Grails 7. Grails 6 depends on libraries that now have
significant CVEs that we can't patch. We need to release Grails 7 in a
workable state so the community can move forward.
Waiting 2 weeks, means waiting 3 weeks (assuming an instant fix) before we
could do a milestone due to ASF voting requirements. That means we
wouldn't release until August, which would likely push a final Grails 7
release all the way past October. This means we wouldn't be able to spend
time on Hibernate 6 and likely further fall behind on Spring boot 4. It
could very well derail the entire ecosystem. Saying "wait this is easy to
fix" without knowing what all of these issues are & contradicting
previous statements made on some of these tickets is not accurate. Not to
mention this isn't one issue and even struts has had issues with upgrading
to sitemesh 3 (https://issues.apache.org/jira/browse/WW-4356).
I have offered to work with you on a side branch to move forward sitemesh 3
in a future grails release. We are no worse than we are in Grails 6 since
Grails 6 uses an even older version of sitemesh. Moreover sitemesh 2 does
not have any external dependencies according to its POM. Just because code
is old, does not mean it's bad. Grails has used it for over a decade now.
We can also take steps in the 2.x code line to minimize dependencies so we
don't break when we switch.
This change is not permanent. It's only to help us release faster. If you
get sitemesh3 working, we can always release Grails 8 in a few months with
the hibernate 6. Let's work on that instead of delaying a release that
everyone else needs that is broken because of these listed 6 issues.
-James
On Thu, Jul 3, 2025 at 12:23 PM Scott Murphy Heiberg <
scottheib...@apache.org> wrote:
> -1 Do not proceed because ...
>
> * Rapid fix is feasible
> I can resolve the outstanding SiteMesh 3 issues in two weeks when my
> schedule frees up.
>
> * Risk of a major functional regression
> Downgrading to SiteMesh 2 undoes years of improvements and re-introduces
> bugs that 7.x has already eliminated.
>
> * Breaks the entire 7.x plugin ecosystem
> Every plugin released for Grails 7 compiled with this reversion will not
> be compatible with future releases. This will force developers to have to
> re-release plugins during the next release cycle further fragmenting the
> community.
>
> * Relies on obsolete, unmaintained code
> The proposal pulls in a fork last touched in 2009. Maintaining that branch
> ourselves means assuming full responsibility for a decade of missing
> security patches and refactorings.
>
> * Licensing back-slide
> SiteMesh 3 is Apache 2.0. The 2.x codebase is still under the non-standard
> OpenSymphony license—one of the main reasons we migrated in the first
> place. Reversion complicates legal compliance for commercial users.
>
> * Unrealistic test coverage
> Grails 7 has been running SiteMesh 3 for 15 months across thousands of CI
> cycles. By contrast, SiteMesh 2 would receive very little time testing
> before a major release—insufficient to surface edge-case failures.
>
> * Wrong 2.x baseline
> If we must downgrade, the logical starting point is the actively developed
> 2.5/2.7 line, not the hastily patched 2.6.0 snapshot. Anything else
> magnifies technical debt.
>
> * Opportunity cost
> Diverting resources to re-integrate and stabilise SiteMesh 2 moves the
> project “ten steps backward.” Investing the same effort into fixing the few
> outstanding issues keeps Grails on a modern, maintained stack and delivers
> value sooner.
>
>
> On 2025/07/02 15:58:16 James Daugherty wrote:
> > Per discussion [1] and the unanimous feedback in the weekly meeting, I'd
> > like to propose we revert to Sitemesh 2.x for Grails 7. Please see the
> > thread for the reasons, but the initial work is here:
> > https://github.com/apache/grails-core/tree/issue14193 The goal would
> be
> > to revert, and work through any issues as they come up.
> >
> > The vote is open for the next 72 hours and passes if all binding votes
> are
> > cast in favor.
> >
> > [] +1 proceed with the proposal
> > [] 0 I don't have a strong opinion about this, but I assume it's ok
> > [] -1 Do not proceed because ...
> >
> > Here is my vote:
> >
> > +1 (binding)
> >
> > -James
> >
> >
> >
> > [1] https://lists.apache.org/thread/8lynrl0yd6ykn749md1g2wjb8jph3s5l
> >
>
