Jenkins SVN plugin failed when removing files (Checksum mismatch) - java

We encounter a strange error with Jenkin today. After investigating, we find that it's due to the fact that we delete some files in SVN, which cause a problem in Jenkin SVN plugin.
As I investigate, it seems this bug was known but it hasn't been fixed yet. So that upgrading to a newer SVN plugin version is not a solution(we are using Jenkin 1.474).
Our temporary fix is that "always checkout before building". But this is clearly very slow and takes much time for big projects. So that I'm looking for a way to (at least) detect the SVN problem in post-build scripts when it happens, and probably send an email to notify the developers.
Does anyone have any experience with this? I'm not too familiar with Jenkin, hence any help or pointer would be greatly appreciated.
Here's the error log:
Building in workspace /workspace-directory/workspace
Cleaning up /var/lib/jenkins/jobs/aaa/workspace/.
Deleting /var/lib/jenkins/jobs/aaa/workspace/logs
Deleting /var/lib/jenkins/jobs/aaa/workspace/target
Updating svn://address/trunk#HEAD
U src/main/some_file.java
D src/main/another_file.java
U src/main/other_files.java
ERROR: Failed to update svn://address/trunk#HEAD
org.tmatesoft.svn.core.SVNException: svn: E155017: Checksum mismatch while updating '/var/lib/jenkins/jobs/aaa/workspace/src/main/address/.svn/text-base/StudioSignUpController.java.svn-base'; expected: '39fc987bbeb8cd332e6b94abfb934720', actual: 'e9fa300ee28a2b1e15b2273f4b14ae18'
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:85)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:69)
at org.tmatesoft.svn.core.internal.io.svn.SVNEditModeReader.driveEditor(SVNEditModeReader.java:250)
at org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryImpl.update(SVNRepositoryImpl.java:1503)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:557)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:414)
at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:324)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27)
at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11)
at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20)
at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1221)
at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:292)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:315)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:295)
at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:391)
at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:136)
at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:789)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:770)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
at hudson.FilePath.act(FilePath.java:842)
at hudson.FilePath.act(FilePath.java:824)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1245)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494)
at hudson.model.Run.execute(Run.java:1488)
at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:477)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Caused by: org.tmatesoft.svn.core.SVNException: svn: E155017: Checksum mismatch while updating '/xxxxx/.svn/text-base/SignUpController.java.svn-base'; expected: '39fc987bbeb8cd332e6b94abfb934720', actual: 'e9fa300ee28a2b1e15b2273f4b14ae18'
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor15.textDeltaEnd(SVNUpdateEditor15.java:637)
at org.tmatesoft.svn.core.internal.wc.SVNAmbientDepthFilterEditor.textDeltaEnd(SVNAmbientDepthFilterEditor.java:221)
at org.tmatesoft.svn.core.internal.wc.SVNCancellableEditor.textDeltaEnd(SVNCancellableEditor.java:130)
at org.tmatesoft.svn.core.internal.io.svn.SVNEditModeReader.processCommand(SVNEditModeReader.java:176)
at org.tmatesoft.svn.core.internal.io.svn.SVNEditModeReader.driveEditor(SVNEditModeReader.java:232)
... 29 more
Caused by: svn: E155017: Checksum mismatch while updating '/xxxx/.svn/text-base/SignUpController.java.svn-base'; expected: '39fc987bbeb8cd332e6b94abfb934720', actual: 'e9fa300ee28a2b1e15b2273f4b14ae18'
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:189)
at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:141)
at org.tmatesoft.svn.core.internal.wc.SVNUpdateEditor15.textDeltaEnd(SVNUpdateEditor15.java:634)
... 33 more
no change for svn://some_address/trunk since the previous build
No emails were triggered.

We have occassionally seen the problem with some builds, but we normally just clear the workspace and then rebuild. (From Jenkins, Navigate to the job, then "Workspace".)
There are a couple of different plugins that may help with detecting and possibly actually taking some actions based on the issue.
Warnings Plugin - parses the console output and looks for built in and user defined patterns that it reports as Warnings.
Log Trigger Plugin - triggers downstream jobs if a specific trigger is found in the console log. (Perhaps have an SVN "clean-up" job that is triggered?)
Of these, I have only used the Warnings Plugin myself.

These threads from Jenkins JIRA and JetBrains are interesting:
https://issues.jenkins-ci.org/browse/JENKINS-14550
http://youtrack.jetbrains.com/issue/IDEA-83673#comment=27-379397
As you mentioned, the issue remains open in Jenkins. JetBrains believe they have corrected IDEA with the updated svnkit: svnkit 1.7.5-v1.
Also noted in the jetbrains issue are some strategies to fix the issue using the commercial tool SmartSvn, an svn client which has a special feature "Validate Admin Area".
I am going to try to update the Jenkins JIRA issue with a note about the svnkit to see if that results in a fix.
EDIT:
Actually, it looks like the January Jenkins Subversion plugin, 1.4.5, takes care of this issue. After installing and manually re-starting, the mismatch went away.

Related

SonarLint throws IllegalStateException -> Failed to read local issue store index

I'm currently working in my Job with Eclipse and Java. We should use SonarLint to get some cleaner code and 'till yesterday everything was fine.
But yesterday morning, when I opened Eclipse, SonarLint throw me the following errormessage.
I've already searched in Google, deleted the .sonarlint folder, also the settingsfolder of eclipse and the .sonarlint folder inside the eclipse-workspace. Everyone of them where recreated by restarting eclipse but nothing helped here. I'm still getting the error:
Starting SonarLint for Eclipse 4.2.0.201909192007
SonarLint processing file /rap-server-core/src/main/java/com/rapidclipse/framework/server/ui/filter/FilterComponent.java...
Starting standalone SonarLint engine 4.2.0.201909192007...
Found 17 issue(s)
Error during execution of SonarLint analysis
java.lang.IllegalStateException: Failed to read local issue store index
at org.sonarlint.eclipse.core.internal.tracking.StringStoreIndex.load(StringStoreIndex.java:55)
at org.sonarlint.eclipse.core.internal.tracking.StringStoreIndex.keys(StringStoreIndex.java:45)
at org.sonarlint.eclipse.core.internal.tracking.IndexedObjectStore.deleteInvalid(IndexedObjectStore.java:78)
at org.sonarlint.eclipse.core.internal.tracking.IssueStore.<init>(IssueStore.java:62)
at org.sonarlint.eclipse.core.internal.SonarLintCorePlugin.lambda$0(SonarLintCorePlugin.java:102)
at org.sonarlint.eclipse.core.internal.tracking.IssueTrackerRegistry.newTracker(IssueTrackerRegistry.java:54)
at org.sonarlint.eclipse.core.internal.tracking.IssueTrackerRegistry.getOrCreate(IssueTrackerRegistry.java:43)
at org.sonarlint.eclipse.core.internal.SonarLintCorePlugin.getOrCreateIssueTracker(SonarLintCorePlugin.java:146)
at org.sonarlint.eclipse.core.internal.jobs.AbstractAnalyzeProjectJob.trackIssues(AbstractAnalyzeProjectJob.java:317)
at org.sonarlint.eclipse.core.internal.jobs.AbstractAnalyzeProjectJob.lambda$15(AbstractAnalyzeProjectJob.java:302)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2295)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2317)
at org.sonarlint.eclipse.core.internal.jobs.AbstractAnalyzeProjectJob.updateMarkers(AbstractAnalyzeProjectJob.java:302)
at org.sonarlint.eclipse.core.internal.jobs.AbstractAnalyzeProjectJob.runAnalysisAndUpdateMarkers(AbstractAnalyzeProjectJob.java:209)
at org.sonarlint.eclipse.core.internal.jobs.AbstractAnalyzeProjectJob.doRun(AbstractAnalyzeProjectJob.java:169)
at org.sonarlint.eclipse.core.internal.jobs.AbstractSonarProjectJob.run(AbstractSonarProjectJob.java:45)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Caused by: com.google.protobuf.InvalidProtocolBufferException: Protocol message contained an invalid tag (zero).
at com.google.protobuf.InvalidProtocolBufferException.invalidTag(InvalidProtocolBufferException.java:102)
at com.google.protobuf.CodedInputStream$StreamDecoder.readTag(CodedInputStream.java:2066)
at org.sonarlint.eclipse.core.internal.proto.Sonarlint$StorageIndex.<init>(Sonarlint.java:2496)
at org.sonarlint.eclipse.core.internal.proto.Sonarlint$StorageIndex.<init>(Sonarlint.java:2482)
at org.sonarlint.eclipse.core.internal.proto.Sonarlint$StorageIndex$1.parsePartialFrom(Sonarlint.java:3126)
at org.sonarlint.eclipse.core.internal.proto.Sonarlint$StorageIndex$1.parsePartialFrom(Sonarlint.java:1)
at com.google.protobuf.AbstractParser.parsePartialFrom(AbstractParser.java:215)
at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:232)
at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:237)
at com.google.protobuf.AbstractParser.parseFrom(AbstractParser.java:48)
at com.google.protobuf.GeneratedMessageV3.parseWithIOException(GeneratedMessageV3.java:332)
at org.sonarlint.eclipse.core.internal.proto.Sonarlint$StorageIndex.parseFrom(Sonarlint.java:2746)
at org.sonarlint.eclipse.core.internal.tracking.StringStoreIndex.load(StringStoreIndex.java:53)
... 16 more
I don't know what the problem is and as I said google couldn't help me that much (maybe I'm just to stupid for google idk)
I had the same problem.
I had tried downgrading from 5.0 to 4.3, but that did not solve the issue.
So I did some investigation and found that in the source code sonarlint-eclipse/org.sonarlint.eclipse.core/src/org/sonarlint/eclipse/core/internal/tracking/StringStoreIndex.java line 53 ultimately lead to public static final String INDEX_FILENAME = "index.pb"; (line 34).
So what I did was del /s /q /f index.pb within the Eclipse, Maven and Workspace folders. And it was under the Workspace .metadata\.plugins folder.
And now, the error seems to be gone. SonarLint is finally reporting on where the "smelly" code is again.
I have a feeling that the permissions for index.pb got messed-up or not updated, and could not load the file as the error message suggested.
But back to normal now. :)
I've just reinstalled Eclipse... now everything works fine again.
I still don't know what problem caus' this error, but now that it's gone I just hope it'll never come back :D
For the reinstalling I've only deleted every folder, who has something to do with eclipse. Except, of course, my workspace folder^^
Update the Sonarlint installed in the IDE.
Steps in Eclipse and STS IDE:
Select Help, then "Eclipse Marketplace", search for SonarLint, click on the Installed Icon, finally select "Update".

How to fix undefined MqttChannelInitializer constructor in HiveMQ Client?

I was using HiveMQ Client version 1.0.1 but I decided to update to the recently released version 1.1. I completely started from scratch and imported the project as a Gradle project and tried to build. The build work only after ignoring a few failed tests. I'm getting 3 errors in 3 different classes. I realize this is likely related to the Dagger dependency injection tool and I had already successfully built the project and added the directory of build/generated/source/apt/main/ to my build path as noted by my previous stack post where I had issues with a DaggerSingletonComponent not being found: How to fix DaggerSingletonComponent not resolved in HiveMQ (MQTT protocol) . This seems to be a new issue and I'm not sure what's wrong. I tried rebuilding by project but the errors still persist. I've left some screenshot below as well as the specific errors.
HiveMQ:
https://github.com/hivemq/hivemq-community-edition
https://github.com/hivemq/hivemq-mqtt-client
Errors:
The constructor MqttChannelInitializer(MqttClientConfig, MqttConnAckFlow, MqttEncoder, MqttConnectHandler, MqttDisconnectHandler, MqttAuthHandler, Lazy) is undefined
The constructor MqttSession(MqttClientConfig, MqttSubscriptionHandler, MqttIncomingQosHandler, MqttOutgoingQosHandler) is undefined
The method provideBootstrap(NettyEventLoopProvider, MqttChannelInitializer) in the type ConnectionModule is not applicable for the arguments (MqttClientConfig, NettyEventLoopProvider, MqttChannelInitializer)
Screenshots:
Executing ./gradlew clean build on the command line will fix your error.
But I also think that the real solution for your use case is to create a new empty project (gradle or maven) and add the client library as a dependency, like described here: https://hivemq.github.io/hivemq-mqtt-client/docs/installation.html
The issue turned out to be caused by an issue with the source folder in the directory build/generated/source/apt/main/ not having the option “Update exclusion filters in other source folders to solve nesting” selected. Selecting that option solved all of the errors.

java.lang.AssertionError: class hudson.plugins.jacoco.JacocoPublisher is missing its descriptor when manually building the plugin

I am trying to use JaCoCo code coverage plugin (3.0.4) in Jenkins (2.138.2). It works as expected, but what I don't like about it is that it does not generate the report when the build is either failed or aborted. This code is here: https://github.com/jenkinsci/jacoco-plugin/blob/master/src/main/java/hudson/plugins/jacoco/JacocoPublisher.java#L585-L587
There is a pull request for this, but looks like it didn't get worked on after its original creation.
So I tried to rebuild the plugin myself with next steps:
Clone https://github.com/jenkinsci/jacoco-plugin
Checkout the latest version 3.0.4
Remove the if statement from above in JacocoPublisher class
Build the plugin (mvn package as they say)
I am able to build it with no problems. The next steps are:
Navigate to Jenkins -> Manage Jenkins -> Manage Plugins -> Advanced
Upload the generated jacoco.hpi file and restart Jenkins
After this is done, the Post Build step to run JaCoCo reports disappears, and I see this in jenkins logs:
06-Nov-2018 17:19:24.353 WARNING [Handling GET /jenkins/job/testing-jacoco-code-coverage-reports/configure from 0:0:0:0:0:0:0:1 : http-nio-8080-exec-3 Job/configure.jelly Project/configure-entries.jelly] hudson.ExpressionFactory2$JexlExpression.evaluate Caught exception evaluating: i.descriptor in /jenkins/job/testing-jacoco-code-coverage-reports/configure. Reason: java.lang.reflect.InvocationTargetException
java.lang.reflect.InvocationTargetException
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
...
Caused by: java.lang.AssertionError: class hudson.plugins.jacoco.JacocoPublisher is missing its descriptor
at jenkins.model.Jenkins.getDescriptorOrDie(Jenkins.java:1517)
at hudson.tasks.Publisher.getDescriptor(Publisher.java:122)
at hudson.tasks.Recorder.getDescriptor(Recorder.java:51)
at hudson.plugins.jacoco.JacocoPublisher.getDescriptor(JacocoPublisher.java:775)
... 168 more
The solution for this issue proposed by Jenkins is not applicable here since the plugin already extends the required classes.
Reverting to previous version (3.0.4 but not of my custom build) makes the build step appear again, but again, is lacking the behavior I need.
Am I missing anything?
Thank you!
After removing the original version, I had to also delete the remaining jacoco plugin files from the /plugins folder. After that, installation went fine.

Hudson plugin, Java error "... disagree on InnerClasses attribute"

I am trying to be able to step through the code of a Hudson plugin called SVNPublisher. I checked out the code for SVNPublisher, used Netbeans to open the project, and clicked "Debug Main project". This results in a Firefox window opening address http://localhost:8080 which shows the Hudson main page. Clicking the "New Job" link results in an error page:
HTTP ERROR: 500
jar:file:/home/francis/svn/svnpublisher/target/work/webapp/WEB-INF/lib/hudson-core-1.319.jar!/lib/hudson/newFromList/form.jelly:43:47: <j:forEach> hudson.scm.SubversionTagAction and hudson.scm.SubversionTagAction$DescriptorImpl disagree on InnerClasses attribute
RequestURI=/newJob
Caused by:
org.apache.commons.jelly.JellyTagException: jar:file:/home/francis/svn/svnpublisher/target/work/webapp/WEB-INF/lib/hudson-core-1.319.jar!/lib/hudson/newFromList/form.jelly:43:47: hudson.scm.SubversionTagAction and hudson.scm.SubversionTagAction$DescriptorImpl disagree on InnerClasses attribute
at org.apache.commons.jelly.impl.TagScript.handleException(TagScript.java:713)
at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:282)
at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95)
...
I am very new to Hudson and not very experienced with Java so I'm pretty much clueless on the meaning of this error.
Can anyone help?
I know this thread is v. old but I have just had this issues and wanted to help anyone else who has is.
I found I got this issue when I had a DescriptorImpl in a class (this is a sub-class of the main class). In my case this is ResourceAxis contains DescriptorImpl.
I started getting this issue when I renamed DescriptorImpl to ResourceDescriptorImpl. Then I started getting the following error message:
Error injecting constructor, java.lang.IncompatibleClassChangeError: org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis and org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis$DescriptorImpl disagree on InnerClasses attribute
at org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis$DescriptorImpl.<init>(ResourceAxis.java:94)
This propted me to change ResourceDescriptorImpl back to DescriptorImpl - as it was complaining about DiscriptorImpl. At that point I got this error message:
Error injecting constructor, java.lang.IncompatibleClassChangeError: org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis and org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis$ResourceDescriptorImpl disagree on InnerClasses attribute
at org.jenkinsci.plugins.matrix_resource_manager.ResourceAxis$ResourceDescriptorImpl.<init>(ResourceAxis.java:94)
This one is complaining about ResourceDescriptorImpl. I realised I was not doing a Clean build each time and that the old compiled code might be causing issues (as I only change one class, so the other may not be re-compiled). If you see this issue try doing a clean build and see if that solves your issue.
Hope this helps.
I'm running into the same issue and unfortunately I haven't been able to resolve it yet either. As VonC mentioned it may have to do with a change in how generics are used between 1.5 and 1.6, this is problemaitc since even if you install a 1.5 version hudson requires 1.6 to build and run via hpi:run.
What I have noticed is that if you install hudson locally (http://wiki.hudson-ci.org/display/HUDSON/Meet+Hudson#MeetHudson-TestDrive) you can use a maven install command to generate an .hpi file of the plugin and install that. I don't get the same error when I do that which makes me think it could be an issue with the hpi:run goal. That should at least let you test any changes you need to make.
Coincidentally I'm the author of that SVN Publish plugin if there are any questions you have. I haven't made any changes recently, but I found this thread because I have some in the works and ran into this issue ;)
Thanks,
Brent

Class file name must end with .class exception in Java Search

I was hoping someone could help me out with a problem I'm having using the java search function in Eclipse on a particular project.
When using the java search on one particular project, I get an error message saying Class file name must end with .class (see stack trace below). This does not seem to be happening on all projects, just one particular one, so perhaps there's something I should try to get rebuilt?
I have already tried Project -> Clean... and Closing Eclipse, deleting all the built class files and restarting Eclipse to no avail.
The only reference I've been able to find on Google for the problem is at http://www.crazysquirrel.com/computing/java/eclipse/error-during-java-search.jspx, but unfortunately his solution (closing, deleting class files, restarting) did not work for me.
If anyone can suggest something to try, or there's any more info I can gather which might help track it's down, I'd greatly appreciate the pointers.
Version: 3.4.0
Build id: I20080617-2000
Also just found this thread - http://www.myeclipseide.com/PNphpBB2-viewtopic-t-20067.html - which indicates the same problem may occur when the project name contains a period. Unfortunately, that's not the case in my setup, so I'm still stuck.
Caused by: java.lang.IllegalArgumentException: Class file name must end with .class
at org.eclipse.jdt.internal.core.PackageFragment.getClassFile(PackageFragment.java:182)
at org.eclipse.jdt.internal.core.util.HandleFactory.createOpenable(HandleFactory.java:109)
at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1177)
at org.eclipse.jdt.internal.core.search.JavaSearchParticipant.locateMatches(JavaSearchParticipant.java:94)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.findMatches(BasicSearchEngine.java:223)
at org.eclipse.jdt.internal.core.search.BasicSearchEngine.search(BasicSearchEngine.java:506)
at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:551)
at org.eclipse.jdt.internal.corext.refactoring.RefactoringSearchEngine.internalSearch(RefactoringSearchEngine.java:142)
at org.eclipse.jdt.internal.corext.refactoring.RefactoringSearchEngine.search(RefactoringSearchEngine.java:129)
at org.eclipse.jdt.internal.corext.refactoring.rename.RenameTypeProcessor.initializeReferences(RenameTypeProcessor.java:594)
at org.eclipse.jdt.internal.corext.refactoring.rename.RenameTypeProcessor.doCheckFinalConditions(RenameTypeProcessor.java:522)
at org.eclipse.jdt.internal.corext.refactoring.rename.JavaRenameProcessor.checkFinalConditions(JavaRenameProcessor.java:45)
at org.eclipse.ltk.core.refactoring.participants.ProcessorBasedRefactoring.checkFinalConditions(ProcessorBasedRefactoring.java:225)
at org.eclipse.ltk.core.refactoring.Refactoring.checkAllConditions(Refactoring.java:160)
at org.eclipse.jdt.internal.ui.refactoring.RefactoringExecutionHelper$Operation.run(RefactoringExecutionHelper.java:77)
at org.eclipse.jdt.internal.core.BatchOperation.executeOperation(BatchOperation.java:39)
at org.eclipse.jdt.internal.core.JavaModelOperation.run(JavaModelOperation.java:709)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1800)
at org.eclipse.jdt.core.JavaCore.run(JavaCore.java:4650)
at org.eclipse.jdt.internal.ui.actions.WorkbenchRunnableAdapter.run(WorkbenchRunnableAdapter.java:92)
at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:121)
Thanks McDowell, closing and opening the project seems to have fixed it (at least for now).
Comment #9 to bug 269820 explains how to delete the search index, which appears to be the solution to a corrupt index whose symptoms are the dreaded
An internal error occurred during: "Items filtering".
Class file name must end with .class
message box.
How to delete the search index:
Close Eclipse
Delete <workspace>/.metadata/.plugins/org.eclipse.jdt.core/*.index
Delete <workspace>/.metadata/.plugins/org.eclipse.jdt.core/savedIndexNames.txt
Start Eclipse again
Two more general-purpose mechanisms for fixing some of Eclipse's idiosyncrasies:
Close and open the project
Delete the project (but not from disk!) and reimport it as an existing project
Failing that, bugs.eclipse.org might provide the answer.
If the workspace is caching something broken, you may be able to delete it by poking around in workspace/.metadata/.plugins. Most of that stuff is fairly transient (though backup and watch for deleted preferences).
Got this error to the other day. Tried deleting the all .class-files and resources from my output folder manually. Didn't work. Restarted my computer (WinXP). Didn't work. Closed my project in Eclipse and opened it again. Worked!!! Hopes this solves someones problem out there. The search facilities and truly essential to Eclipse.
I also encountered this issue recently, the below scenario worked for me.
Close Eclipse
Delete <workspace>/.metadata/.plugins/org.eclipse.jdt.core/*.index
Delete <workspace>/.metadata/.plugins/org.eclipse.jdt.core/savedIndexNames.txt
Start Eclipse again
Closing the projects didn't do the trick for me. I started eclipse with the -clean flag and that worked for some reason.
Just
Close project
Clear manually output folder(s)
Open project
(Eclipse 3.5 SR2, Build id: 20100218-1602)

Categories

Resources