Update the Java server framework

[BrapiCoordinatorSelby]

Upgrade the underlying server framework to Spring or similar. Jetty is outdated and becoming somewhat difficult to maintain.

[daveneti]

I am looking at creating an updated version of BRAVA that makes use of spring framework. The goal will be to reorganize the code into separate gradle modules, I propose

• core - The code validation code and any util classes such as reporting etc.
• db - The database persistence layer using spring data
• app - The spring app, exposes the core and db via rest services
• cli - the command line version that uses the core - most likely using picocli
• web - a simple GUI that uses the app

[langeipk]

IPK appreciates this engagement and fully supports it! Thank you very much!

[patrick-koenig]

Jetty is outdated and becoming somewhat difficult to maintain.

Peter, can you clarify on this statement? I'm wondering because the latest Jetty version 11.0.13 was released in December 2022. In BRAVA we are currently on Jetty 11.0.11 which is super close to the latest version 11.0.13. I can't imagine why there would be any difficulties with maintenance now? And it was you, Peter, who did the update to Jetty 11 (see commit 286485c).

And in production (I mean https://webapps.ipk-gatersleben.de/brapivalidator) we have used Tomcat as servlet container. Jetty was used only as development server and did the job very well.
Spring Boot uses Tomcat as default, but one could also switch to Jetty. I see no advantage in refactoring to Spring/Spring Boot.

If you're going to refactor the backend, why not use a modern framework optimized for containerization and cloud-native operation like Quarkus or Micronaut?

[BrapiCoordinatorSelby]

@patrick-koenig Thank you, you are completely correct to question me on this. To be honest, it has more to do with my own perception than any facts. I used to work with Jetty 9-10 years ago and I remember it being painful to configure. I have only started working with Spring in the past 4-5 years and it still seems new and easy to me.

Am I correct that there is a want/need to refactor the current Java code base into something a little more standard, service model oriented? Spring would be my first choice because I'm most familiar with it and I could help build and maintain it quickly. I haven't had an opportunity to work with Quarkus or Micronaut.

@daveneti has offered to volunteer some of his time to refactor BRAVA, so I want to make the project meaningful and enjoyable to him. At the same time, I don't want to take the ownership of BRAVA away from you guys at IPK.

[daveneti]

The proposal is to split the core validation code away from the code that exposes the validation as a rest service. From what I can see from reviews of Quarkus, Micronaut and Spring is that there are pros and cons of each. The main advantage Quarkus or Micronaut over spring seems to to be startup time and memory footprint. I don't have any experience in either Quarkus or Micronaut, however the first step would be to refactor the code validation code which has a dependency on rest assured and write some tests for these. I don't think we need to commit to a specific web framework at this time. Next step would refactoring the CLI module, I would avoid spring for that, but recommend picocli. Then look to see how to expose the validation code as a service, which could be Quarkus, Micronaut or Spring, or perhaps all three? Finally write a web application, I don't have any experience in React yet, but it could be Angular or Vue, or even a simple thymeleaf application. On the topic of containerisation I have used docker images of spring boot in k8s for a few years now. For the web framework discussion we would need to iterate though each of the use cases for running BRAVA, from CLI to k8s, lambda or anything in between.

[BrapiCoordinatorSelby]

@patrick-koenig @langeipk
We would like to propose a new github repo be opened, so that it is easier for @daveneti and myself to untangle the existing BRAVA code and better organize it into the modules suggested above. I propose the new repository be named /plantbreeding/BRAVA2.

This is a pretty major refactoring effort we have in mind. To an outside observer, it might look like we are going to start our own project instead of contributing back to your existing work. I want to be clear that this is NOT the case. I want IPK to stay involved as the leadership for the BRAVA project, even if you do not currently have the time/resources to work on it directly. I want to be able to give BRAVA some major upgrades it deserves, but I don't want to take away any of IPKs credit of ownership and I don't want to hurt anyone's ego.

Please let me know, either here or privately, if you are uncomfortable with any of this. As @daveneti indicated above, he will begin with a refactoring the core code. we have plenty of time to make a plan and come to a consensus on everything. I just want to make sure we do it together.

[cpommier]

Hi,

having a major refactor from time to time is indeed part of the software lifecycle. It is great to see the current discussions on that matter, though I haven't followed it. I salute the will to respect everybody's autorship and ownership. It is not a surprise in our community but always pleasant to spot :) .

Just my two pences: having two repository (BRAVA and BRAVA2) will make it a little bit less understandable for outsiders. Maybe having a new branch for the refactor, with the first commit as a full rm -rf./* before adding the new modules ? There is a risk of a branch hell though.

[langeipk]

My recommendation is to go the way of a branch and start it from scratch. This has the advantage that cherry picking can be done from the original branch, code transfer and thus also propagated (design) errors are traceable and the old version can still be maintained until the completion of version BRAVA 2.0. All issues also remain referencable etc. Just like this issue.

A new repo is somehow also a new branch, only with limited possibilities.

It can also be useful for building user trust if a repo exists for a long time and is maintained permanently. Scientists are sometimes like shy deer. I am therefore in favour of proposal @cpommier

[BrapiCoordinatorSelby]

Ok thanks for the input everyone!
I have created a new branch BRAVA-2-main which is an empty branch with a README and a gitignore file. I have setup up some protection rules so that only @patrick-koenig @langeipk @daveneti and myself can commit directly to that branch. Others need to submit a pull request just like any other main/master branch.

Please let me know if something doesn't work, or if I need to do anything else in the setup for this.

[langeipk]

thanks @BrapiCoordinatorSelby and @daveneti for taking responsibility here. branch permissions should work, will see in next commit.