Hello, I've posted a new draft PR for hbase-thirdparty introducing toolchain-based builds: PR https://github.com/apache/hbase-thirdparty/pull/142.
(Below is same as before i.e. adds back reverted commit 6016e75d38312c9e78a4594d363c29ce24b82bc4) This adds new modules for Jetty 12 migration. Branches using EE8 should update dependencies to these modules. Future modules for EE9/EE10 can be added as needed. (New change as suggested by Istvan) The build now uses Maven toolchains, supporting both JDK 8 and JDK 17 in one branch. It auto-selects the correct JDK, simplifies local/CI setup, and keeps JDK 8 compatibility for existing modules. Documentation and setup scripts are included. This changes also addresses HBASE-29354 i.e. https://github.com/apache/hbase-thirdparty/pull/139 Please note: Jenkins integration is still a work in progress. With this, HBase 2.x can continue using JDK 8-compatible Jetty 9, while HBase 3.x can adopt Jetty 12 on JDK 17: all in a single branch with clear Jenkins/CI and local developer workflows. This eliminates the need for separate branches or releases for different JDK/Jetty versions. Looking forward to your feedback on the draft PR. Regards, Nihal On 2025/05/27 04:45:49 Istvan Toth wrote: > 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> > ------------------------------ > ------------------------------ >
