> When updating HAL, we should keep in mind that the test suite can be adapted with minimal effort.

Exactly. When we are counting the effort of different approaches. Keep in mind we have currently 3 different active WebConsole testsuites. Any change to HAL will cause changes to all of those 3 testsuites.
- https://github.com/hal/berg
- https://github.com/hal/manatoko
- https://github.com/hal/testsuite.next

On Wed, Aug 2, 2023 at 11:23 AM Harald Pehl <hpehl@redhat.com> wrote:
With the latest release of PatternFly 5 [1], I'd like to open a discussion about the future of the HAL codebase and possible major updates.

HAL currently depends on PatternFly 3.x, released on Feb 1st, 2016 [2]. PatternFly 3.x itself depends on many old JS dependencies like jQuery 3.x and Bootstrap 3.x, which are either no longer supported [3] or don't receive new updates.

While HAL itself is pretty stable, this brings the danger that we run into CVEs that can no longer be fixed simply by updating the dependency. One possible solution would be to update to the latest PatternFly version. This would have more advantages:

- Fresh, new look and feel
- Enhance user experience
- Align with other consoles like OpenShift & Keycloak

I see two basic approaches when updating to PatternFly 5:

1. Switch the technical stack to TypeScript & React

Pros:
- Recommended way how to use PatternFly
- Well documented
- Active community
- State of the art

Cons:
- Rewrite HAL from scratch
- Hard to re-use existing codebase
- Technology-independent building blocks like DMR-related code, RBAC security checks, and model-based UI would be lost
- Weak expertise
- Contributors need to adapt

2. Stick with the current architecture (Java & GWT) and migrate the codebase

Pros:
- Technology-independent building blocks can be re-used
- Could also be the foundation of halOS
- Well-known and rock-solid architecture
- Strong expertise
- Some work has already been done [4]

Cons:
- GWT community does still exist, but it is small and not very active
- Rewrite a lot of UI-related code

Finally, we should consider the following issues:

- With the focus on running WildFly in the cloud, do we really need to make this effort? Is it worth it?
- When updating HAL, we should keep in mind that the test suite can be adapted with minimal effort.

Before going into any direction, I'm keen to hear what you think about it. Suggestions, ideas, and critics are welcome!

---
Harald Pehl
JBoss by Red Hat

[1] https://www.patternfly.org/get-started/upgrade
[2] https://github.com/patternfly/patternfly-3/releases/tag/v3.0.0
[3] https://blog.getbootstrap.com/2019/07/24/lts-plan/
[4] https://github.com/patternfly-java
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@lists.jboss.org
Privacy Statement: https://www.redhat.com/en/about/privacy-policy
List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message/JUNIM42V5ESNQXJ2S4MO4ZIY7S6KE327/