-
Notifications
You must be signed in to change notification settings - Fork 116
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
[Runtime] Embed Maven 3.9.1 #1238
Conversation
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.
@Eskibear Currently Maven 3.9.x has some breaking changes, so before we use it we need to wait until most plugins have adopted to it or find a way to let the user choose the embedded maven version.
Thank for the info. I somehow managed to make it compile by b582ab6
Do we have a list of these plugin and status of their compatibility with 3.9.0? Let me know if there's anything I can help. |
...enarchiver/src/org/eclipse/m2e/mavenarchiver/internal/AbstractMavenArchiverConfigurator.java
Outdated
Show resolved
Hide resolved
3.9.0 is out for a few days so I won't expect much testing here, but best is to test different projects with 3.9.0 and report issues to the plugin authors. |
Got it. Then let's wait a longer time for it... In the meanwhile, I'll do some tests as suggested. |
If you like just go on in fixing thing in m2e itself (so we are ready for 3.9.x) this already causes some test failures, so we probably need more adjustments here. |
Most of the failures are caused by missing class Lacking the context information ,I'm not sure why it's excluded historically, and whether it will work after we include it. I can give it a try and dig deeper anyway. m2e-core/m2e-maven-runtime/org.eclipse.m2e.maven.runtime/pom.xml Lines 55 to 58 in 0b49dca
|
Usually we exclude all what is not strictly required to keep the downloadsize small, if it is now a requirement it could be included. |
By including aopalliance, we got 60 failed cases passed. The remaining 19 are:
|
Test Results 198 files ±0 198 suites ±0 30m 57s ⏱️ + 6m 52s For more details on these failures, see this check. Results for commit 7674069. ± Comparison against base commit 43bba83. ♻️ This comment has been updated with latest results. |
Maven 3.9.1 has been released. So you probably want to update to that version directly. |
Thanks for the info. |
tycho-baseline-plugin is unhappy, but I don't think I should update all related versions in this PR just for that. I remember previously it's skipped in Jenkins CI build. Any idea? |
It seems that there are some bytecode changes in the compiled code that now are getting visible, we are currently looking into this! |
@Eskibear if you rebase your branch the baseline problem should be fixed now! |
Thanks, I'll revert 67b3cf2 and try rebase. BTW, I'm looking into below error:
I find lots of errors are related to missing maven-resources-plugin:3.3.0, and it's indeed not existing in https://github.com/tesla/m2e-core-tests/tree/c3acc1aa00a37eb9bdcebe8ad88d29233e1a4c71/org.eclipse.m2e.tests/repositories/remoterepo/org/apache/maven/plugins/maven-resources-plugin |
Maybe we should just add Maven-Central as another repo? |
I agree. That would make it much easier for new contributors who don't have a whole picture of the repo yet. |
You can prepare and open a PR for the tests submodule from your fork and then temporarliy adjust the .gitmodules file in this repo to point to the branch in your fork. |
@laeubi After the rebase, it seems the baseline problem still exists.
logs from https://ci.eclipse.org/m2e/job/m2e/job/PR-1238/37/console |
This class extends |
The baseline issue is gone, after I updated some versions following the plugin's suggestion. As for the missing maven-resources-plugin:3.3.0 in m2e-core-tests, I followed #1238 (comment) with a commit Eskibear/m2e-core-tests@93d053c , adding .jar and .pom manually. Now it did found the artifact, but reporting below error messages:
I'm wondering if it's because parent POM & dependencies should also be added. BTW, I browsed some commits in m2e-core-tests, finding .pom and .jar files are usually added in batch. Two questions:
|
6b1a801
to
38adad1
Compare
@HannesWell Thank you for the help!!!
Totally agree, especially due to potential changes like this in output format, which is not guaranteed to stay the same.
It looks promising, polling with some reasonable timeout would be simpe and effective. Notification mechanism is better but might have requirements on upstream projects like surefire plugin.
This looks too hacky to me and the processes are not launched in a common way that we want to guard? Above are just my two cents given my limited knowledge about m2e, maybe further discussion can happen in another issue like #471 . And again, thank you Hannes for fixing test failures and explainig the root cause underneath! Now I think this PR should be ready for review. |
It is indeed hacky, but the main idea is to also be able to inject jdwp arguments in forked java processes, so that M2E can control if forked java-process will wait for a debugger or not, without the need to have a mapping for the configuration of each Plugin.
You are very welcome and thanks for your work and your patience as well. Btw. I created a competing PR for the m2e-core-tests repo to remove all artifacts in the embedded But this could be a lengthy task, so I'm not sure if this is worth it. If I don't succeed over the weekend I will merge your PR tesla/m2e-core-tests#199 so that we can proceed here. But I think we are close to the finish line here. :) |
The lemminx failure is most likely related. I will try to reproduce it locally soon. I'll prioritize it to allow more progress here. Please ping me in the beginning of next week if I didn't give news on this topic, as I may have forgotten about it over the week-end. |
I couldn't reproduce the lemminx.tests issue in my IDE from both HEAD of this PR, and also after a rebase on top of master, neither in my IDE nor with command-line |
I cannot reproduce the lemminx failure either. Let me rebase it on top of the master branch. UPDATE:
|
Just a reminder that before merging this PR, we probably need to merge tesla/m2e-core-tests#199 first and update submodule. |
Great, so it looks like this was just bad luck. 👍🏽
Yes, I'm also making progress in #1330 respectively tesla/m2e-core-tests#200 and it should now be down to at most one test failure. I plan to finish that within the next day(s) and therefore would like to keep tesla/m2e-core-tests#199 open until the former one is merged. |
Now that #1130 is merged I rebased this PR on top of the current master and squashed all commits and added myself as co-auther. Feel free to add some more comments to the commit message if you think it is necessary.
From the latter we know it occasionally fails and the latter occured before and you fixed it with adding more resources to the embedded remoterepo. However I was not able to reproduce it locally, so lets see if this was by chance as well. |
Feel free to merge it. Thank you! |
Forgot to mention:
This requires an update of the test case as tesla/m2e-core-tests@49e2b22 See https://github.com/apache/maven/blob/maven-3.9.1/maven-core/src/main/resources/META-INF/plexus/default-bindings.xml#L43-L45 for reference. |
For your convenience, I create tesla/m2e-core-tests#201 , which I believe can also be merged at the time you merge this PR. |
72ee8cd
to
c42cf5e
Compare
Co-authored-by: Hannes Wellmann <[email protected]> Signed-off-by: Yan Zhang <[email protected]>
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.
Thanks a lot @Eskibear for this non trivial contribution and your patience.
This is highly appreciated.
See #1169 (comment)