I've gone ahead and decoupled the revert in the PRs so that there shouldn't
be any concern about breaking the 7.x plugin ecosystem.  As Mattias said,
we've never had this concern previously and this could always happen
anyhow.  But this change should ensure it doesn't happen for the sitemesh
related changes.

On Fri, Jul 4, 2025 at 3:02 AM Søren Berg Glasius <soe...@glasius.dk> wrote:

> Hi Scott,
>
> I really value the effort you've put into modernizing Grails — the work on
> SiteMesh 3 has set an important direction.
>
> I agree with many of your concerns, especially long-term ones like
> licensing and maintenance.
>
> That said, I also share James and Mattias’ view that in the short term, we
> need to get Grails 7 out the door. The broken layout scenarios are critical
> regressions that affect day-to-day use, and the path back to stability
> seems clearer with the release of Grails 7, with Sitemesh2, 2.6.x or even
> 2.7.x
>
> I’d like to see a roadmap emerge where Sitemesh 3 comes back stronger in
> Grails 8 — ideally alongside Hibernate 6 and other big lifts. Let's not
> lose that momentum, and please consider helping with Sitemesh 2.7.0.
>
> Den fre. 4. jul. 2025 kl. 00.13 skrev Mattias Reichel <
> mattias.reic...@gmail.com>:
>
> >  Scott, I know this is disappointing, with all the work you have put in.
> > However, I think this ship has sailed, but there is always the next one.
> >
> > Some comments on you points below:
> >
> > * Rapid fix is feasible
> > * I can resolve the outstanding SiteMesh 3 issues in two weeks when my
> > schedule frees up.
> >
> > Time has run out and these issues have been on the board for 8+ months.
> >
> > * Risk of a major functional regression
> > * Downgrading to SiteMesh 2 undoes years of improvements and
> re-introduces
> > bugs that 7.x has already eliminated.
> >
> > Grails 6 is using Sitemesh 2.4.4 and I'm not aware of any bugs.
> > Which bugs are re-introduced?
> >
> > * 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.
> >
> > This has always been the case, right?
> > Anyway, I think Grails 8 will follow pretty rapidly with other libraries
> > doing major version jumps.
> >
> > * 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.
> >
> > When I look at the project, the 2.4.x branch seems to have had 36 commits
> > and 2 releases with the last 2.4.4 release 2023-08-13.
> > The 2.6.x branch that is continuing this line has had work done in 2024
> > updating it to Java 17 and migration to Jakarta.
> >
> > * 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.
> >
> > The OpenSymphony license seems to be derivative of the Apache License
> with
> > some additions regarding naming and mentions.
> >
> > * 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.
> >
> > I think this is actually the opposite. Some tests seem to have been
> removed
> > with the upgrade to Sitemesh 3 and some had to be annotated with @Ignore
> > or @PendingFeature until the issues could be resolved, which they have
> not
> > yet. James' branch is to my knowledge now passing on all reintroduced and
> > previously muted tests.
> >
> > * 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.
> >
> > As I read
> >
> https://github.com/apache/grails-core/issues/13058#issuecomment-1631552275
> > the easiest path would be the continuation of 2.4.x which is 2.6.x.
> > Also it seems Grace is using Sitemesh 2.6.x in 2024.0.x.
> >
> > * 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.
> >
> > I'm not so worried about this, we can always upgrade again later when the
> > integration is ready for it.
> >
> >
> > Den tors 3 juli 2025 kl 18:23 skrev Scott Murphy Heiberg <
> > scottheib...@apache.org>:
> >
> > > -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
> > > >
> > >
> >
>
>
> --
>
> Med venlig hilsen,
> Søren Berg Glasius
>
> Hedevej 1, Gl. Rye, 8680 Ry
> Mobile: +45 40 44 91 88
> --- Press ESC once to quit - twice to save the changes.
>

Reply via email to