Hi, I agree with the proposed single branch strategy. I also agree with temporarily reverting/disabling Jetty 12 until after the next thirdparty release.
Regarding the Java compiler version: According to https://stackoverflow.com/questions/12414209/compile-maven-module-with-different-java-version Using different compilers in a single project is possible. The toolchains solution does require some extra setup for compiling, but seems easily doable both manually and in the release script / CI. So the question comes down to: - Either require a bit more involved environment setup for building thirdparty with toolchains - Or maintaining and releasing two separate branches The single branch solution still seems to be much less work overall. Istvan On Mon, May 26, 2025 at 7:15 PM Nihal Jain <nihalj...@apache.org> wrote: > Hi team, > > As a follow-up to our earlier discussion on Jetty 12 support and the > proposed branching strategy for hbase-thirdparty, I wanted to share an > update based on the recent dry-run of the 4.1.11 release (HBASE-29302). > > During the deploy step, the build failed due to bytecode version > violations enforced by the maven-enforcer-plugin. Specifically, the Jetty > 12 modules added via HBASE-29225 which are known to be compiled with JDK > 17, violate our strict JDK 8 bytecode compatibility requirement for the > project. > > To address this, we created HBASE-29354 and to resolve the immediate issue > by overriding the max bytecode version to 17 for Jetty 12 specific > modules—since these modules only relocate pre-compiled JDK 17 .class files > and are not supposed to be consumed by branch-2.x. While this seemed to > resolve the build failure, some concerns were raised during the PR > discussion regarding the correctness of this approach and hence we did not > go ahead with merging this change. > > Given that the Jetty 12 modules are not required for the HBase 2.x > branches, and this issue is currently blocking the 4.1.11 release (which is > needed for the upcoming 2.6.x and 2.5.x releases), we discussed to > temporarily revert the Jetty 12-related changes from the main branch. A > revert PR has been raised at PR #140. > > Once the 2.x release is complete, we’ll revisit Jetty 12 integration with > a cleaner strategy aligned with the HBase 3.x line and JDK 17 support. > > Please let me know if you have any concerns or suggestions. > > Best regards, > Nihal Jain > > On 2025/05/23 09:52:55 Nihal Jain wrote: > > Thank you for your input, Duo. I agree that the longevity of the 2.x > release support is a crucial factor in deciding our approach. > > > > Even I think Istvan is in favor of single branch strategy for now, > including me, for maintenance concerns. As you already mentioned, we can > revisit the branching strategy once the adoption of 3.x becomes more > widespread and the activity around 2.x decreases. > > > > I will wait for others' input, if any, for the next few hours. If there > are no further objections, I will initiate the hbase-thirdparty 4.1.11 > release process later tonight (IST). > > > > Regards, > > Nihal > > > > On 2025/05/23 07:48:48 "张铎(Duo Zhang)" wrote: > > > After consideration, I think maybe the key thing here is how long we > > > still plan to support frequent 2.x releases. > > > > > > So I think we could go with one branch for now, and once 3.x becomes a > > > more popular release and 2.x gets less active, we can go with the two > > > branches solution. > > > > > > Thanks. > > > > > > Nihal Jain <nihaljain...@gmail.com> 于2025年5月22日周四 15:27写道： > > > > > > > > Hi team, > > > > > > > > I hope you're all doing well. I am writing to initiate a discussion > > > > regarding the upcoming release of hbase-thirdparty and our plans to > > > > integrate significant updates, including the addition of a Jetty 12 > module > > > > as part of > > > > https://issues.apache.org/jira/browse/HBASE-29225 > > > > > > > > --- > > > > > > > > Currently, our plan is to set Jetty 12 with EE8 for branch-3+, while > > > > branch-2 will continue using Jetty 9. > > > > > > > > For this, we have introduced a new module in hbase-thirdparty, which > > > > includes: > > > > - hbase-shaded-jetty-12-plus-core: Contains shaded Jetty 12 core > jars. > > > > - hbase-shaded-jetty-12-plus-ee8: Contains shaded Jetty EE8 specific > jars. > > > > > > > > Branches that want to consume EE8 will need to add both the > > > > `hbase-shaded-jetty-12-plus-core` and > `hbase-shaded-jetty-12-plus-ee8` > > > > dependencies, replacing the former `hbase-shaded-jetty`. In the > future, we > > > > plan to introduce additional modules for EE9/EE10 as needed. > > > > > > > > Refer https://issues.apache.org/jira/browse/HBASE-29224 > > > > > > > > --- > > > > > > > > There's been a proposal to manage this via separate branches in > > > > hbase-thirdparty: > > > > > > > > 1. **Master Branch (5.x) for HBase-3+:** > > > > - Incorporate Jetty 12 changes. > > > > - Transition to support JDK 17 and hbase-unsafe eventually > > > > > > > > 2. **Fork Branch (4.x) for HBase-2.x:** > > > > - Continue using Jetty 9. > > > > - Maintain support for JDK 8. > > > > > > > > Refer https://issues.apache.org/jira/browse/HBASE-29302 > > > > > > > > While this allows for modularized changes, it might increase our > > > > maintenance workload as going forward we may have to backport to both > > > > branches of hbase-thirdparty, as needed, and drive twice the number > of > > > > releases for the same. > > > > > > > > An alternative could be maintaining a single branch with duplicated > modules > > > > specific to jetty versions to reduce release workload but this will > prevent > > > > us from moving to JDK 17. > > > > > > > > --- > > > > > > > > I welcome your thoughts on our strategy for handling these updates > and on > > > > managing the branch strategy for hbase-thirdparty. > > > > > > > > Please let me know if you have any concerns or additional > suggestions. Your > > > > input will be invaluable as we refine our approach to this release. > > > > > > > > Looking forward to your feedback. > > > > > > > > Best regards, > > > > Nihal Jain > > > > > > -- *István Tóth* | Sr. Staff Software Engineer *Email*: st...@cloudera.com cloudera.com <https://www.cloudera.com> [image: Cloudera] <https://www.cloudera.com/> [image: Cloudera on Twitter] <https://twitter.com/cloudera> [image: Cloudera on Facebook] <https://www.facebook.com/cloudera> [image: Cloudera on LinkedIn] <https://www.linkedin.com/company/cloudera> ------------------------------ ------------------------------
