TEZ-4654: Migrate from commons-lang2.x to commons-lang3.x #441
+65
−63
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Contributor
Author
This comment was marked as outdated.
This comment was marked as outdated.
Aggarwal-Raghav
force-pushed
the
TEZ-4654
branch
from
25ee1ed to
cafecd5
Compare
Contributor
Author
|
Looks like UT failures are because of exclusion of common-lang 2.x in From Hive perspective, commons-lang 2.x is part of hive-exec jar so, it shouldn't cause any runtime issues as well. https://github.com/apache/hive/blob/c054a47c7c22875c93ca0d29b7ac730cf7deba04/ql/pom.xml#L1060 CC @abstractdog |
This comment was marked as outdated.
This comment was marked as outdated.
Contributor
|
@Aggarwal-Raghav : I can see only 1 problem in tez-javadoc-tools while compiling the java 17+ version |
Contributor
Author
@abstractdog , it is passing in local. Attaching the build logs for this module. Do i need to force push again? |
Contributor
Author
|
Please suggest, what needs to be done. |
Contributor
sorry for the late reply, it has passed for me too locally, can you rebase and push to see it now? and then we'll decide |
- Upgrade to commons-lang-3.19.0 - org.apache.commons.lang.ArrayUtils => org.apache.commons.lang3.ArrayUtils - org.apache.commons.lang.RandomStringUtils => org.apache.commons.lang3.RandomStringUtils - org.apache.commons.lang.StringEscapeUtils => org.apache.commons.lang3.StringEscapeUtils - org.apache.commons.lang.StringUtils => org.apache.commons.lang3.StringUtils - org.apache.commons.lang.SystemUtils => org.apache.commons.lang3.SystemUtils - org.apache.commons.lang.exception.ExceptionUtils => org.apache.commons.lang3.exception.ExceptionUtils - org.apache.commons.lang.mutable.MutableInt => org.apache.commons.lang3.mutable.MutableInt - org.apache.commons.lang.NotImplementedException => org.apache.commons.lang3.NotImplementedException
Aggarwal-Raghav
force-pushed
the
TEZ-4654
branch
from
cafecd5 to
c884d63
Compare
Contributor
Author
|
No Worries. Rebased |
|
💔 -1 overall
This message was automatically generated. |
Contributor
|
looks good to me, spotbugs should be fixed though in TEZ-4669 |
Contributor
I'll double-check the javadoc tools build, because it's weird...it compiles for me locally too |
Contributor
Author
|
I'm speculating and might be wrong but is it possible that the |
Contributor
Author
As its not able to find the previously build modules |
Contributor
but right before these modules' build, there is e.g. tez-dag build as shown in which ends with: I cannot reproduce this locally now, and now it's not only tez-javadoc-tools but also tez-tests more interestingly, tez-runtime-internals builds successfully, even though it's complaining about tez-api, which it depends on: |
Contributor
|
I just hacked yetus to add -X to maven command and explode, will see :) |
|
💔 -1 overall
This message was automatically generated. |
Contributor
|
@Aggarwal-Raghav spotbugs report showing -1 for all modules. It is failed due to below error. Can you check it ? |
Contributor
already tracked on TEZ-4669 |
Contributor
|
debug level maven logs revealed new exotic things: so invalid POM is some missing version, but still don't get how could this come in precommit and not locally |
Contributor
|
reproduced the maven compile problem on an ubuntu server by hitting the same commands as yetus: again, the same didn't happen on my mac |
Contributor
Author
|
I'll also look into this over the weekend. |
Contributor
Author
|
Can we remove this |
Contributor
I'm afraid we cannot, this is deep inside yetus logic, how it identifies the affected modules and their dependencies, and build them one by one |
Contributor
|
ignore my last comment about effective pom, it was wrong, deleted it |
Contributor
|
hm, strange, now I can repro the same locally too :D |
Contributor
Author
|
I'm also able to repro with the steps you have shared on mac but @abstractdog , isn't this way of doing things wrong? if clean the ~/.m2/repository cache and build the modules like |
Contributor
Author
That's what I was suspecting yesterday as well. Maybe I couldn't communicate it better. |
Contributor
I agree that building the project module by module is not necessarily the most optimal way, because we can figure out what went wrong even if the whole project is built in one go, I'm totally fine with a patch where the maven build phase is done in one go, and as a positive side effect, this issue would also go away |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
4 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.