linuxfun

Does this preserve Java 8 compatibility? No, target is set to 11 in the parent pom. This change was introduced by the first set of changes done by Alexey. I kept this in as I don't see value in keeping compatibility with an ancient java version. Does this require service interfaces to upgrade to the jakarta.* packages to continue to work? Changes are necessary for the teavm facing parts. These must be updated. It might be possible to recognize both variants, but I don't think it is worth it. Oracle...

Patch is available from https://sourceforge.net/p/flavour/tickets/10/

Update to teavm 0.11.0

As another note: I'm willing to extract my changes and provide them in any form necessary/helpful (patch or some other type of contribution).

The question git vs. subversion is independent of the question github vs. sourceforge. Sourceforge can handle projects on git basis, so there is no need to switch hosting.

Hi, I had a look at flavor and noticed, that is was not current. Current regarding the teavm version used and not current regarding the java version required to build. I got my hands dirty making the required changes to port the project to teavm 0.11.0 and make it possible to build with JDK 17+21. Porting in this case means, that unittests and integration tests work and the example is also runnable again. Given that my work was based on the original authors start of porting to the jakarta-Namespace...

I assume that the teasampler uses an HTTP server, that serves the index.html from the root of the deployment when a subpath is requested, that does not exist physically. That is doable with Apache, but also using a servlet (the latter requiring you to implement it). The HTML code is served as the body of the 404 response. Why no 200 is used is beyond me.

Hi, I had a look at flavor and noticed, that is was not current. Current regarding the teavm version used and not current regarding the java version required to build. I got my hands dirty making the required changes to port the project to teavm 0.11.0 and make it possible to build with JDK 17+21. Porting in this case means, that unittests and integration tests work and the example is also runnable again. Given that my work was based on the original authors start of porting to the jakarta-Namespace...