Should be fixed when the website rebuilds. If now prints out some additional fields from the Metadata, including Status, if found. Some of the Metadata fields for individual GEPs might need a slight refresh in some cases.
On Wed, Apr 29, 2026 at 12:48 AM Jochen Theodorou <[email protected]> wrote: > Hey Paul, > > I'd like to suggest a change to https://groovy.apache.org/wiki/geps.html > It would be very nice to see the status of the GEP in the GEP lists, or > partition the GEP lists into their states. That way one could easily see > what GEPs are refused or implemented and where something is still to do. > I am asking because the list starts becoming long. I mean that is great, > but you have to go through over 20 GEPs now to see which are done and > which not. What do you think? > > bye Jochen > > On 4/27/26 23:17, Paul King wrote: > > I created a very early alpha GEP capturing a version of Eric's idea: > > > > https://github.com/apache/groovy-website/blob/asf-site/site/src/site/ > > wiki/GEP-21.adoc <https://github.com/apache/groovy-website/blob/asf- > > site/site/src/site/wiki/GEP-21.adoc> > > > > https://groovy.apache.org/wiki/GEP-21.html <https://groovy.apache.org/ > > wiki/GEP-21.html> > > > > It was mostly Claude and I haven't vetted it properly yet, so it might > > have some holes/hallucinations, but it should serve as a suitable > > starting point for an on-going conversation. > > > > I would also be keen to help progress this, but more than happy if > > someone else wants to take the lead. > > > > Cheers, Paul. > > > > > > On Tue, Apr 28, 2026 at 1:53 AM Jochen Theodorou <[email protected] > > <mailto:[email protected]>> wrote: > > > > On 4/27/26 16:35, Milles, Eric (TR Technology) via dev wrote: > > [...] > > > In general, I think the expectation is that we offer a single > source > > > folder that can have bi-directional dependencies between groovy > > and java > > > sources. > > > > it would actually be interesting to know more about the expectations > of > > our users here > > > > > In practice, this has probably reached a good-enough state. > > > The cost of supporting the last 20% -- features like @Delegate, > > > @Builder, and so on -- may or may not be worth the complexity or > > risk. > > > > agreed > > > > > I have considered the idea of split-phase AST transforms. For > > example, > > > if a transform can run in CONVERSION or SEMANTIC_ANALYSIS to add > > some > > > tags (annotations, interfaces, metadata, ...) or stub elements > > (fields, > > > methods, inner classes, ...). Then a second pass of the > > transform runs > > > in CANONICALIZATION or INSTRUCTION_SELECTION to finish off the > code > > > generation. This sort of thing could help with java stubs. > > > > yes, plus the transform could carry a marker interface that shows it > is > > joint compilation friendly. > > > > bye Jochen > > > >
