On 2 Aug 2023, at 10:22, Harald Pehl <hpehl(a)redhat.com&gt; 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(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)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...

Hi Harald, It looks like a difficult decision. I just read it and wanted to comment on one minor point in line. On Wed, Aug 2, 2023 at 10:23 AM Harald Pehl <hpehl(a)redhat.com&gt; 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? > It is not only OpenShift/Kubernetes but also the traditional deployments such as VM in Azure or AWS. In such an environment, the users would continue using the traditional Web Console shipped with the server. So I see it relevant even with the focus on the cloud. > - 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(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)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... > _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)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...

Hi Harald, It looks like a difficult decision. I just read it and wanted to comment on one minor point in line. On Wed, Aug 2, 2023 at 10:23 AM Harald Pehl <hpehl(a)redhat.com&gt; 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? > It is not only OpenShift/Kubernetes but also the traditional deployments such as VM in Azure or AWS. In such an environment, the users would continue using the traditional Web Console shipped with the server. So I see it relevant even with the focus on the cloud.

> - 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(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)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... > _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)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...

> Does this mean it is likely that in a few years we will be having the same > discussion we're having now re jQuery and Bootstrap, but instead about GWT? That's a fair point. I can't guarantee that, but we never had a CVE in GWT in the last 10 years. > Putting on my old finance hat, we need to think in terms of amortizing the > effort of a rework strategy over the expected life of the result. In this respect, I'd say it's less effort to migrate the codebase than to switch to TypeScript / React.

> It also seems likely to me that aspect of the HAL tooling will end up being > incorporated into consoles provided by cloud ecosystems, particularly > OpenShift. Of course you know this from your efforts in this area, Harald. > From a naive engineering POV it seems good if there is shared code between > those elements and the traditional web console. Sorry; I guess this is one > of your Pros above. :) Exactly. I envision some basic building blocks, that are re-used in both HAL and halOS. _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)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...