NihalJain commented on PR #131: URL: https://github.com/apache/hbase-thirdparty/pull/131#issuecomment-2758238036
> > > As bad a jetty12 would be a bad name, at least we're not tying it to the ee spec version. Maybe jetty-new ? or Jetty-b ? > > > > > > I am not sure if I understand you correctly but we may need all versions of jetty to exist: > > > > * [hbase-shaded-jetty](https://issues.apache.org/jira/browse/HBASE-shaded-jetty): for <= branch-2.6 > > * [hbase-shaded-jetty-ee8](https://issues.apache.org/jira/browse/HBASE-shaded-jetty-ee8): possibly for branch-2, if we decide to backport retaining javax namespace > > * [hbase-shaded-jetty-ee9](https://issues.apache.org/jira/browse/HBASE-shaded-jetty-ee9): For branch-3+ with jakarta namespace change > > > > Hence created a new module for ee8 as first step. > > AFAICT ee8 and ee9 does not have to be a separate project. IUC the different modules can co-exist because they are under different package names. > > So we could maintain a single [hbase-shaded-netty-whatever](https://issues.apache.org/jira/browse/HBASE-shaded-netty-whatever) package, that includes ee8 for now, and we can add ee9 later (while retaining ee8 for older hbase branches). Okay got your point. Agreed, created 2 modules as we have a javax dependency inside thirdparty jetty (not sure why), copied same inside new module. If we can build without this bundled, then we should be good maybe. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
