move all groovy-related code from "framework" to "fastergt"

[asolntsev]

it allows to fully avoid Groovy dependencies for users with another templating engine (e.g. Kotlin templates).

[xabolcs]

It would be nice to reference issue #65 in the commit message. 🙏

[xabolcs]

Just viewing the diff ... : do these lines have an alternative? Or can be implemented somehow?

[asolntsev]

@xabolcs I just checked that classes FastTags and JavaExtensions do NOT have any static fields. Also, these classes don't have children. There is nothing to inject.

[xabolcs]

Answering my own question: one could move the needed code to the plugin's onApplicationStart().
For example see what cies' did in PR #227!

[xabolcs]

Not tested, but the diff looks good

[xabolcs]

There were talk about the 40x and 50x templates in how / why they need the Groovy dependency.

If it's still valid, it would be nice to see a few words / snippet in the README, or just a link to an example test app in replay-tests. What do you think?

[cies]

I find it odd that framework still has GT code (the templates), while it does not have the ability to execute it. See framework/src/errors and framework/src/tags. My PR has "prepared to deal with that": as I explain in the discussion of the issue. I wanted to move all GT-code (the templates) out of framework but that needs additional work (and given that my PR was already considered too big, I'm glad I did not put in that effort).

I'm not sure how you handle errors when the fastergt lib dependency is not around. With my PR one can bring their own ErrorHandler (see the interface in my PR and the SimpleErrorHandler implementation for showing pretty errors w/o GT).

In order to test your PR, I'd move the test cases from my PR to your PR and see how they are handled. I'm afraid in your PR there is no way to serve "pretty error pages" without the fastergt lib loaded.

My end goal is to completely free framework from GT-code (template code): my PR only implements step 1/2 of that goal. I think a little GT-handling code needs to stay in framework (as I explain in the discussion of the issue), but that's fairly minimal. Also: I want to be able to script pretty error pages with "my templating solution of choice", instead of still being locked into using GT for that (and thus not being able to get rid of Groovy in production).

[asolntsev]

I'm not sure how you handle errors when the fastergt lib dependency is not around.

I suggest a very simple approach.
Users need to have at least some template engine. By default, it's fastergt, and users can replace fastergt by some other dependency if they wish (like Kotlin templates in your case).

[asolntsev]

I find it odd that framework still has GT code (the templates)

I understand your concern. Yes, probably we should move all these classes to "fastergt" module.
Initially, I left them in "framework" just because they might be useful for authors of other templating engines. Don't you need them in your Kotlin engine?

[xabolcs]

Users need to have at least some template engine.

May I ask to document this new framework requirement somewhere else too? In the commit description / in the README / in a talkative Exception message?

[asolntsev]

@xabolcs @cies Just in case, I think this PR is finished. I've moved other templates-related classes to "fastergt" module.

But you can continue with #227 if you wish. No preference from my side.

[asolntsev]

May I ask to document this new framework requirement somewhere else too?

This is not a new requirement, actually. :)
This requirement existed in Replay from the very beginning. I just didn't realize it. :)

Yes, we could write it to README, I think.
And I'll try to improve the error message as well (in case if user has not added any templating engines).

[cies]

lgtm!