-
Notifications
You must be signed in to change notification settings - Fork 111
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
Bug 570279 - Maven repository indexing error: java.nio.channels.OverlappingFileLockException #169
Comments
IMHO, the problem is in |
@vrubezhny thanks for the analysis here, do you think you can take care of maven-indexer get fixed (create ticket/PR?) we can then close this ticket once the indexer is fixed and the dependency is upgraded. |
@laeubi I believe I can provide the fix (I think it should be enough just to remove one method call from the
but I hadn't had a chance to test it yet. |
I think first step would be to open an issue here: https://issues.apache.org/jira/projects/MINDEXER If you link the reported issue and a PR here I'm sure there will be people help in supporting the fix. |
@laeubi Thank you for the links. I have reported the issue against maven-indexer: https://issues.apache.org/jira/browse/MINDEXER-127 and created a PR with the fix proposed above: apache/maven-indexer#105 |
Until the bug in maven-indexer is fixed and incorporated into M2E, is there a work-around? Can the repository index be deleted and built again from scratch? |
Yes, you can for sure try that manually (when you IDE is off). I'm not certain where the index files are based, but looking at the code of |
Did you mean in code? I think the follwing code could be used to delete and re-create a new context instead of purging the same context with
This is not very nice, because it is actually deprecated code, but the whole class contains a lot of deprecated code and should be reworked anyway. |
I wouldn't mind having such workaround in, even with deprecated code, as long as it contains a clear reference to issue upstream in the Maven indexer. |
It would be good to prepare a PR which uses snapshots (from https://repository.apache.org/content/repositories/snapshots/org/apache/maven/indexer/indexer-core/6.1.0-SNAPSHOT/ ) to verify it fixes m2e's issue before the release of indexer. |
A test PR was created a while ago and show indexer 6.1.0-SNAPSHOT was making tests pass: #284 |
…ption(eclipse-m2e#169)" This reverts commit c485103 since moving to indexer-6.1.0 makes the workaround useless.
This should be fixed now thanks to c485103 from @HannesWell . Please install newer snapshots from https://download.eclipse.org/technology/m2e/snapshots/latest/ and verify it fixes your issue, and reopen or comment is issue persists. |
newer snapshots from https://download.eclipse.org/technology/m2e/snapshots/latest/ do install Eclipse.org - m2e M2E Maven Integration for Eclipse Core 1.18.2.20211011-2139; This feature comprises <plugin id="org.eclipse.m2e.maven.indexer" |
Can you please show the stacktrace? It should be at least different now. |
Thanks Mika I have actually tried Spring Tools 4.12 (Eclipse 4.21), 4.11 (Eclipse 4.20), 4.10 (Eclipse 4.19) and they all fail with this same error. After installation, going to maven > settings, import my settings, that does a re-index: fail. If I switch to a former Spring Tools 3.9 / Eclipse 4.8, it works like a breeze. I just tried with a plain vanilla Eclipse build and get the same, hence not bound to SpringTools bundle. Here is eclipse.buildId=4.22.0.I20210929-1800 Message: "Unable to re-index workspace://", or I see too in error log: "Reindexing error", yet same stack trace java.nio.channels.OverlappingFileLockException Note that I have a settings.xml with NEXUS mirrors and local repo set to C:/java/.m2/repository (which Eclipse 4.8 re-indexes fine) Installed software panel reports: |
This version is from the time before the work-around was implemented. With that work-around Please make sure you have installed the latest release, that was just published today, from the release repo: Or as described here: https://github.com/eclipse-m2e/m2e-core#-installation The provided Eclipse packages for 2021-09 do not yet contain that release and instead use the previous release that does not contain the work-around. |
Well observed. Yet I always installed from ...m2e/releases/latest/ and the outcome was version 1.18.2.20211011-2139 next to successful installation. Just retried with my initial SpringToolsSuite 4.12 / Exclipse 4.21 and this time I got again (as listed in my very first post to this track) 1.18.2.20211011-2139. It fails again, same stack trace as above, and I note that I have now both "org.eclipse.m2e.maven.indexer_1.18.0.20210618-2246" and "org.eclipse.m2e.maven.indexer_1.18.1.20211011-2139" in plugins directory! (all "org.eclipse.m2e." are duplicated). Last observation: you mention a indexer v6.1 hereabove that "passes tests". Everything I see in my plugins, else even downloading org.eclipse.m2e.maven.indexer_1.18.1.20211011-2139.jar from https://download.eclipse.org/technology/m2e/snapshots/latest/plugins/ is the version 6.0 |
question: is there a way I could inject in e.g. Eclipse 4.19+ an older feature/plugin version for m2e that works? like the one bundled in my eclipse 4.8... |
I see the error popup, but I don't see the stack trace. Where did you get it? |
Version 6.1 is the version of
Sure. You can any previous release from these repos: |
When I click on the maven:user settings:reindex button there's always 2 new error lines in the Eclipse "Error log" view: one labelled "Reindexing error" with plug-in column containing "org.eclipse.m2e.core" and the second labelled "Unable to re-index workspace://" with plug-in column containing "org.eclipse.m2e.logback.appender". When I double click in any of those 2 rows, I get the same stack trace (same call sequence, same line numbers) still visible 6 posts hereabove.
I fully believe you. There's actually something quite weird if we think about: I don't have any error with an old Eclipse 4.8 installation. I have this same error with all of 4.19, 4.20, 4.21, 4.22. I can't reasonably believe that the bug is there for every developer since 4 releases at least, un-noticed till April 10. There's surely some interference with an external component or setting... elsewhere.... and if NexusIndexManager.java:561 can't match with version 1.18.2.20211011-2139, that means the classloader picks something else somewhere... in my context, not everyones' context. Hence a simple first check: I opened a command shell, forced the PATH to just the JDK11 JRE, same for JAVA_HOME, ensure no CLASSPATH defined, and launched a SpringToolSuite 4.12==Eclipse 4.21 and .... it did not cause any error!! no longer any indexing error visible in the Error log view from launch, and no error when I click on the maven:user settings:reindex button. So I triggered a first 'maven install' from the "run as" context menu on a first project: passed! then a second with a dependency on the first: failed. Maven failed to resolve the jar that was however present in .m2/repository (I double checked). I also tried to reindex via the "Maven Repositories" view > Local repo > Rebuild Index: no effect at all and no tree expanding below the Local Repository. I decided to exit Eclipse, erase the .m2/repository/*, and relaunch from the SAME command line. Indexing error is back!!! but now with a different stack trace: (from 'error log' view): (see notably NexusIndexManager.java:574 now!) how could it be? Exit, back to command line, echo %PATH% ... unaffected! Hence, I decided to restore the .m2/repository, and launch. Whether I launch with an empty PATH from the command line, else from the start menu, I just have one "Reindexing error" message, and the above stack trace (i.e. calling through NexusIndexManager.java:574). I noted one more thing: I can now reindex from the "Maven Repositories" View > Local Repositories > Local Repository > (right-click) Rebuild Index without error. Previously, that had no effect (no error in error log either!) and I was not able to drill down the artefact tree from within the "Maven Repositories" View. And a very last one: I can build one child POM project, if I try to build a second sibling project that has a dependency on the first, it fails to resolve the existing artefact in .m2/repository. If I trigger the "run as " > Maven Install from the Parent POM, then it builds the first, and then second OK. |
I have a possible explanation of all the weird observations in the previous post, and further up. (1) in my context, the .m2/repository was inherited for a long history of builds with Eclipse 4.8. I upgraded to SpringToolsSuite 4.12 that is a bundle of Eclipse 4.21, and a reindex of that same repo, causing a 'outdated' (sic) stack trace with "NexusIndexManager.java:561" . I tried installations of Eclipse 4.19 to 4.22, same 'outdated' stack trace - 100% true observation. On the other hand, your automated test environment and a majority of developers likely do not experiment this combination of a jump from 4.8 to 4.21 with a PATH like mine. Henceforth it is likely that combination of PATH and repo state that triggers the 'outdated' error. (2) The change to the PATH before launch definitely "unlocked" some situation, likely: changed the repo state - a 95% certainty. (3) when I first relaunched Eclipse 4.21 with a truncated PATH, the re-indexing error vanished - a 100% true observation. Yet it does not mean the index was built... at all. And actually I am pretty sure now (90% certainty) the re-indexing exited almost immediately, not causing any error by the same token, but did not build any index either. Fact is, trying "Maven Repositories" view > Local repo > Rebuild Index had no effect at all (100% certainty). No index, no expanding tree of local .m2 artifacts, and unable to build a project with a dependency on a former although the artifact was present in .m2. Yet, no "indexing" error elsewhere. (4) I then erased the repo, and restarted Eclipse, point at which I saw the new reindexing stack trace (cf previous post) through NexusIndexManager.java:574. It does fail when invoked from preferences > Maven > Settings > reindex, but not via "Maven Repositories" view > Local repo > Rebuild Index. (100% reproductible). And now I can browse the tree of artefacts in .m2 local repo under "Maven Repositories" view. However, the build of a second project with a dependency on a former project still fails to locate the first project artefact although present in .m2/repository; failing when invoked isolated, and succeeding when both project builds are invoked in a single run via the Parent POM. (5) when I tried to reproduce the initial 'outdated' stack trace, I must acknowledge that I no longer had the repo (and notably what was under .m2/repository/.cache) in the state that matched with the 'outdated' stack traces. My restoration is actually a version post item (3) hereabove. Conclusion: the re-indexing code launches something that is affected by a combination of PATH and a repo state inherited from an Eclipse 4.8. That caused the 'outdated' stack trace (through NexusIndexManager.java:561). This applied to all eclipse versions at least since 4.19 with m2e version 1.18.2.20211011-2139 installed or not! (because I always tried before and after the patch). Truncated PATH on same repo state inherited from 4.8 builds no index (and no error) - with m2e version 1.18.2.20211011-2139 installed. Same PATH or truncated PATH (no observed difference) on a fresh new repo - with m2e version 1.18.2.20211011-2139 installed - yields the alternative stack trace through NexusIndexManager.java:574 (cf trace in previous post) when invoked via Preferences window and reindex button. No error occurs when a rebuild index is invoked via the "Maven Repositories" view. 'run as " > Maven install fails on sibling project dependencies when invoked on child projects, but succeeds when invoked as one build session on the parent POM / project. |
See #381 |
Thanks for the new stacktrace. That's quite helpful. |
Saw M2E version 1.18.3.20211018-0804 in .../m2e/snapshots/latest and installed in my Eclipse 4.21 / SpringToolsSuite 4.12
Looks solved. GREAT thanks. More extensive use will follow tomorrow - rebuilding ~100 artefacts. I'll post any findings but I'm confident. |
The errors you see are not related to indexing as the index is not involved in dependency resolution (it's only used for some contextual assistance when editing). So please open a separate ticket, ideally with details about how to reproduce this issue. |
https://bugs.eclipse.org/bugs/show_bug.cgi?id=570279
Issue originally reported by Baldurien on bugs.eclipse.org additionally observed by me as described below in fresh install of Eclipse 4.19.0 (2021-03) on Windows 10 Pro.
Note that MB reported in the original bug that:
Original bug report description:
The text was updated successfully, but these errors were encountered: