-
Notifications
You must be signed in to change notification settings - Fork 50
HBASE-29354 Jetty12 dependencies compiled with JDK17 violate hbase-thirdparty bytecode restrictions #139
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Conversation
…irdparty bytecode restrictions
</dependency> | ||
<dependency> | ||
<groupId>org.eclipse.jetty</groupId> | ||
<artifactId>jetty-xml</artifactId> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
unrelated spotless issue, can also fix as another commit
Ran
|
This comment has been minimized.
This comment has been minimized.
🎊 +1 overall
This message was automatically generated. |
@@ -218,6 +218,23 @@ | |||
</execution> | |||
</executions> | |||
</plugin> | |||
<!-- This module relocates Jetty 12+ EE8 dependencies compiled with JDK 17, hence, overriding the project-level | |||
restriction on maxJdkVersion of 'compileSource'! See HBASE-29354--> | |||
<plugin> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So here we do not need to compile this, just relocate the pre compiled .class file, which means we do not need to compile this module with JDK17 right?
We used to relocate some jackson classes for JDK9+ too, strange that why there is no problem for it in the past...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes we do not compile with jdk 17 here. I had even tested out most flows on master even without this change, and things looked good.
Given we wont use these modules for branch 2, shouldnt we be fine with this?
If you think this is not an acceptable approach and we need to think deeper on this, should I drop jetty 12 modules from our main pom temporarily? Or i could rever the jetty change also.
We need release for branch 2.x. This is blocking the upcoming release!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could revert the jetty changes first, make thirdparty 4.1.11 a regular release so we can make the 2.6.x and 2.5.x release, and then back to the jetty 12 related things for 3.x.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure sounds good to me to unblock, let me revert jetty commit, we can come back here once done with 2.x release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better also mention this on the discussion thread on mailing list.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes sure let me put up over there. Also, I have raised PR to revert at #140
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Better also mention this on the discussion thread on mailing list.
Done!
maxJdkVersion
to 17 in the jetty12 related modules