- This topic has 15 replies, 6 voices, and was last updated 15 years ago by
.
-
Posts
-
Hi All,
is 7.1.1 supposed to work correctly with Eclipse 3.4.2 on Windows XP Prof. SP2 or SP3?
If no, I shouldn’t upgrade for now, so I better know it in advance. Also in this case, consider this a VERY urgent feature request for a very soon coming 7.1.2 release :-), because IMHO it is quite unacceptable for ME to not be installable on the latest STABLE Eclipse point release at the time of releasing that ME version (and in this case we do not speak about a brand new yearly Eclipse major release) :-(.
Thanks and best regards,
Robert
Thanks Ray for the answer.
Robert, as Ray mentioned, the base for ME 7.1.1 is Eclipse 3.4.1. MyEclipse is planning a new release – ME 7.5 which is going to be based on Eclipse 3.4.2, which is likely to be released end of May. Thanks for your support and patience.
Joy,
sorry to say so, but this is ridiculous… Eclipse 3.4.2 was released on February 11th, more than a month before 7.1.1 was released. It is now April, more than a month after 7.1.1.
Subclipse 1.6 (which version is required to connect and work properly with Subversion 1.6) does not work correctly with 3.4.1. We upgraded our SVN servers to 1.6. The fact that ME does not support 3.4.2 means I can’t upgrade to 3.4.2 and due to that I either can’t commit to Subversion or can’t use ME.
You should really do a new release ASAP which is feature equivalent to 7.1.1 (no additional features, only bugfixes) which works properly on 3.4.2, and not make everyone wait yet another 2 months (or even more considering the likely delays). I don’t believe that it takes too much time to do a new release which just upgrades dependencies for a newer point release and adds no new functionality. We are not speaking about a new release train here. That would possibly delay 7.5 yet another 2 weeks, but that is acceptable in the face of being able to work properly with Subversion 1.6 ASAP.
I don’t really care about 7.5 while I am not able to work comfortably NOW.
Best regards,
Robert
Robert,
I understand your frustration, but MyEclipse 7.5 is just not an upgrade to Base Eclipse 3.4.2. It consists of a lot of new features and issue fixes from ME 7.1.1. If you take a look at the features list, you can understand that MyEclipse offers a lot of goodies. Like every product, every release has a life cycle, we cannot circumvent anything, but let me assure you that all hands are on the deck and we are trying for an early may release.
Inconvinience caused is sincerely regretted.
Joy,
that (that it is not just an upgrade to 3.4.2) is exactly my problem with 7.5 being developed instead of 7.1.2. You are again losing the focus on providing a USABLE work environment as your first goal and features in that environment as second, contrary to features which will come some months later and until then not being able to use anything due to incompatibilities.
I don’t even understand why 7.1.1 (which itself was a bugfix release) was released at all, knowing that at its release it was already incompatible with the at the time (for more than a month) latest stable release (3.4.2) of the Eclipse platform generation it targeted (3.4), and when it was released why you did not start working at once on fixing that incompatibility. This misery has been prolonged for several months. We are not speaking about something which was discovered yesterday. You must have been aware of it at the time of 7.1.1 being released.
That is why I said that you should do a new release ASAP which is nothing more than bugfixes and support of 3.4.2 and no additional features and postpone 7.5 development until this problem is rectified.
People are forced either not to use your product or not to use Subversion 1.6.
An inconvenience should not be regretted for months (as it has already been), but removed in 2 weeks. I very much doubt it would take more than that to do a 7.1.2 release which ensures Eclipse 3.4.2 compatibility.
I cannot really trust a “we are trying for an early may release.” statement when in a previous post you said “likely to be released end of May”. A 7.1.2 release would surely be doable in 2 weeks, a new feature release is surely not going to be finished in 3 weeks when it did not even enter QA (and from your posts I have to assume that it did not, otherwise you would already have stated that), and even if it did, then probably it would just be another source of frustration due to the insufficient time it was rushed through QA.
I hope you people start looking at real usability issues again, before new features, because lately that has been ignored a bit. New features do not help a software when it is not feasible to use it.
Please do a 7.1.2 release ASAP and continue with 7.5 release only thereafter, and then concentrate on upgrading 7.5 to Eclipse 3.5 so that there is a release compatible with the latest release train as soon after 3.5 release as possible.
Best regards,
Robert
Subclipse 1.6 (which version is required to connect and work properly with Subversion 1.6) does not work correctly with 3.4.1.
Maybe that’s a hint. Why doesn’t Subclipse 1.6 work with 3.4.1? Maybe there are more than what you and I would consider 0.0.1 changes in Eclipse between 3.4.1 and 3.4.2. Shouldn’t it be easier to get a single plugin to work between the two than a large bundle of plugins? Just wondering.
Switching to SVN 1.6 would have required an Impact Analysis for all parties involved, including Eclipse / MyEclipse and their connectors. This should have avoided you from first converting your server and repositories and now complaining that ‘MyEclipse is not on par’ with what you are demanding.
Yes, I agree it’s annoying that ME is not compatible with Eclipse 3.4.2, but as rmcvay already stated, maybe Eclipse has a bit more ‘changed’ than the 0.0.1 increment makes you (and Genuitec) expect.
Obviously you are dependent on the features and capabilities of MyEclipse, so it would have been wise to wait a little longer, upgrading your SVN servers, now that there is no fitting Subclipse plugin for your setup. You can always use the TortoiseSVN shell-extension that is compatible with SVN 1.6, to update and commit your work.HTH
TonRobert,
I can feel the frustration from your post, but I can’t help but feel like it’s all misdirected at *us* as a side effect of the SVN fiasco you ran into with upgrading your repository.
We’ve been very clear with out requirements for months, there are no surprises here on our end. 7.1.1 was never intended to be 3.4.2 compatible and came out 2 weeks after 3.4.2 dropped — those 2 weeks 7.1.1 was already in QA, and there was no way we were restarting QA just to grab that huge unknown refresh in 3.4.2 — I know from a user perspective it looks like all patches and fixes and “Why not get the latest!?” — but it’s not, we’ve broken releases before when we blindly accepted patch releases… it’s a side effect of the Eclipse release train being so mammoth.
MyEclipse 7.5 is the last 3.4.x release, and will have a milestone in May and a release in June. In the August we’ll have an M1 release of 8.0, which will be based on Eclipse 3.5 — I can appreciate that this must be frustrating for folks that like to stay on the cutting edge, but there are huge, literal costs associated with every single release we do. You are talking about 800+ plugins that need to move around ontop of most of the Eclipse tier-1 dependencies and a good majority of the tier-2 and 3 dependencies as well… this isn’t easy stuff and these decisions are not made lightly.
In your venting you mentioned that we should be focused on a more stable experience and not new features — you are exactly right — we are — and these very conservative release cycles with long QA runs in them are exactly what we do to make sure we ship you guys stable products.
We’ve been doing this for a long time (you know, you’ve been here longer than most everyone else) — so you’ve been here with us during the releases that we broke because we’d do an Eclipse refresh right before a release, or not lock our plugin requirements down and let our users ugprade their own installs… you’ve been there when moving to a new Eclipse platform killed half the product… you, more than anyone, probably understands why we work the way we do now. We don’t want any down-time for you guys.
As for an immediate solution to your problem (and I’m aware that it sucks and you likely don’t want to do it), I’d +1 Ton’s idea of using Tortoise temporarily for the 1.6 support until we get 7.5 out the door. I wish I had a more agreeable solution for you right now, but I don’t.
Update: Another support tech saw this thread and hit me up separately and asked if there is a technical limitation to adding Subclipse 1.6 to MyEclipse 7.1 or if it’s just a misunderstanding of how the Add/Remove flows work… I wasn’t entirely sure I realized.
Incase the issue is just getting Subclipse 1.6 installed, you can do that no problem, here’s an FAQ entry for the process:
http://www.myeclipseide.com/index.php?name=PNphpBB2&file=viewtopic&t=23453&start=0&postdays=0&postorder=asc&highlight=If the problem was something else, let me know.
@huisma13 wrote:
Switching to SVN 1.6 would have required an Impact Analysis for all parties involved, including Eclipse / MyEclipse and their connectors. This should have avoided you from first converting your server and repositories and now complaining that ‘MyEclipse is not on par’ with what you are demanding.
Yes, I agree it’s annoying that ME is not compatible with Eclipse 3.4.2, but as rmcvay already stated, maybe Eclipse has a bit more ‘changed’ than the 0.0.1 increment makes you (and Genuitec) expect.
Obviously you are dependent on the features and capabilities of MyEclipse, so it would have been wise to wait a little longer, upgrading your SVN servers, now that there is no fitting Subclipse plugin for your setup. You can always use the TortoiseSVN shell-extension that is compatible with SVN 1.6, to update and commit your work.HTH
TonHi Ton,
I don’t have a control on what is installed on our SVN servers.
That however does not change the fact that ME does not support the latest stable Eclipse release which has been released for more than two months ago and plans not to provide that compatibility for at least another one and a half months. Thats a 3.5 months not supporting the last stable Eclipse release which is not a new release train.
Best regards,
Robert
@robvarga wrote:
I don’t have a control on what is installed on our SVN servers.
You should IMHO be/have a decisive vote on the upgrading process, or at least the moment of the upgrade, as you are a major user of the SVN service/server.
@robvarga wrote:
That however does not change the fact that ME does not support the latest stable Eclipse release which has been released for …
The reasoning for this has been very clearly explained by Riyad, no need to re-argue about it.
Overviewing our development process, I see that upgrades like that, including ME versions, lag behind usually several versions, with some colleagues still running ME 6.01 and others (Vista users) on the latest 7.1.1… It can take a lot of time just to get the right people organized for major (server)upgrades like that.
As shown it is quite easy to install the Subclipse plug-in, and work with the configuration you need.
HTH
@support-rkalla wrote:
Robert,
I can feel the frustration from your post, but I can’t help but feel like it’s all misdirected at *us* as a side effect of the SVN fiasco you ran into with upgrading your repository.
We’ve been very clear with out requirements for months, there are no surprises here on our end. 7.1.1 was never intended to be 3.4.2 compatible and came out 2 weeks after 3.4.2 dropped — those 2 weeks 7.1.1 was already in QA, and there was no way we were restarting QA just to grab that huge unknown refresh in 3.4.2 — I know from a user perspective it looks like all patches and fixes and “Why not get the latest!?” — but it’s not, we’ve broken releases before when we blindly accepted patch releases… it’s a side effect of the Eclipse release train being so mammoth.
Hi Riyad,
Eclipse 3.4.2 was released on Feb 13th. If 7.1.1 came out 2 weeks afterwards, that is Feb 27h. That and the Apr 6-7th release dates currently displayed on the download page means that there was another release of 7.1.1 which more than a month later still did not corrected this incompatibility, and we are asked to wait yet another month or more for a compatible release which is just a milestone not a GA release. That is an estimation of 3 months to wait for a milestone release and yet another month to a GA if it is not delayed at all. And that is optimistic considering the expectable delays.
This is why I am frustrated and the fact that I am experiencing other problems (e.g. simple class rename in Eclipse not working in certain cases and I can’t pin down what causes this) which hopefully would be fixed with 3.4.2.
@support-rkalla wrote:
MyEclipse 7.5 is the last 3.4.x release, and will have a milestone in May and a release in June. In the August we’ll have an M1 release of 8.0, which will be based on Eclipse 3.5 — I can appreciate that this must be frustrating for folks that like to stay on the cutting edge, but there are huge, literal costs associated with every single release we do. You are talking about 800+ plugins that need to move around ontop of most of the Eclipse tier-1 dependencies and a good majority of the tier-2 and 3 dependencies as well… this isn’t easy stuff and these decisions are not made lightly.
I am not really concerned at the moment with 3.5, I was willing to wait for a new ME version first supporting a new Eclipse release train in the past, and that does not change.
But patch releases should be supported in a much more timely manner.
@support-rkalla wrote:
In your venting you mentioned that we should be focused on a more stable experience and not new features — you are exactly right — we are — and these very conservative release cycles with long QA runs in them are exactly what we do to make sure we ship you guys stable products.
We’ve been doing this for a long time (you know, you’ve been here longer than most everyone else) — so you’ve been here with us during the releases that we broke because we’d do an Eclipse refresh right before a release, or not lock our plugin requirements down and let our users ugprade their own installs… you’ve been there when moving to a new Eclipse platform killed half the product… you, more than anyone, probably understands why we work the way we do now. We don’t want any down-time for you guys.
As for an immediate solution to your problem (and I’m aware that it sucks and you likely don’t want to do it), I’d +1 Ton’s idea of using Tortoise temporarily for the 1.6 support until we get 7.5 out the door. I wish I had a more agreeable solution for you right now, but I don’t.
Unfortunately if I upgrade Tortoise then I have to uninstall Subclipse otherwise it will very likely start crapping out exceptions due to the locally upgraded working copy.
And it was not installing which was reported to not work with Subclipse, instead they complained about things being broken with 3.4.1 and Subclipse 1.6. But as I do have problems anyway (unable to commit), I may even try that out now.
Sorry if I offended anyone, but still, having to wait for 3-4 months for an Eclipse patch release (particularly the last ever to come from that release train) to be supported is a bit, let’s say, unusual and harsh.
Best regards,
Robert
Robert,
We’re spending a lot of time talking about Eclipse 3.4.2, but it seems the real issue is that you want to install Subclipse 1.6 into MyEclipse 7.1, right?
Did you miss Riyad’s post that links to our FAQ that shows how to install Subclipse 1.6 into MyEclipse 7.1.1?
If I understand correctly, this whole issue around Eclipse 3.4.2 was started under the false assumption that 3.4.2 was required for you to run Subclipse 1.6. That is not the case. The FAQ shows explicitly how to install Subclipse 1.6 into MyEclipse 7.1.1 and that should result in the configuration you want.
Scott,
this whole issue started with that assumption and also on a couple of other bugs I am facing which I hope 3.4.2 would fix. So Subclipse is one of my problems but not the only one of them.
Another of them is that I keep encountering a problem when I can’t rename a simple Java class because it silently just aborts renaming with the class name changed back to the original. I hope that would be fixed with 3.4.2. If not then I don’t know what causes it. I saw the following exception in the log when that happened:
!ENTRY org.eclipse.jdt.ui 4 10001 2009-04-14 10:59:36.917 !MESSAGE Internal Error !STACK 0 java.lang.reflect.InvocationTargetException at org.eclipse.jface.operation.ModalContext.run(ModalContext.java:415) at org.eclipse.jface.window.ApplicationWindow$1.run(ApplicationWindow.java:758) at org.eclipse.swt.custom.BusyIndicator.showWhile(BusyIndicator.java:70) at org.eclipse.jface.window.ApplicationWindow.run(ApplicationWindow.java:755) at org.eclipse.ui.internal.WorkbenchWindow.run(WorkbenchWindow.java:2487) at org.eclipse.jdt.internal.ui.refactoring.RefactoringExecutionHelper.perform(RefactoringExecutionHelper.java:194) at org.eclipse.jdt.internal.ui.refactoring.RefactoringExecutionHelper.perform(RefactoringExecutionHelper.java:146) at org.eclipse.jdt.ui.refactoring.RenameSupport.perform(RenameSupport.java:198) at org.eclipse.jdt.internal.ui.refactoring.reorg.RenameLinkedMode.doRename(RenameLinkedMode.java:338) at org.eclipse.jdt.internal.ui.refactoring.reorg.RenameLinkedMode$EditorSynchronizer.left(RenameLinkedMode.java:111) at org.eclipse.jface.text.link.LinkedModeModel.exit(LinkedModeModel.java:341) at org.eclipse.jface.text.link.LinkedModeUI$4.run(LinkedModeUI.java:1199) at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:35) at org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchronizer.java:133) at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.java:3800) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:3425) at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.java:2382) at org.eclipse.ui.internal.Workbench.runUI(Workbench.java:2346) at org.eclipse.ui.internal.Workbench.access$4(Workbench.java:2198) at org.eclipse.ui.internal.Workbench$5.run(Workbench.java:493) at org.eclipse.core.databinding.observable.Realm.runWithDefault(Realm.java:288) at org.eclipse.ui.internal.Workbench.createAndRunWorkbench(Workbench.java:488) at org.eclipse.ui.PlatformUI.createAndRunWorkbench(PlatformUI.java:149) at org.eclipse.ui.internal.ide.application.IDEApplication.start(IDEApplication.java:113) at org.eclipse.equinox.internal.app.EclipseAppHandle.run(EclipseAppHandle.java:193) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.runApplication(EclipseAppLauncher.java:110) at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:79) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:386) at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:179) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:549) at org.eclipse.equinox.launcher.Main.basicRun(Main.java:504) at org.eclipse.equinox.launcher.Main.run(Main.java:1236) at org.eclipse.equinox.launcher.Main.main(Main.java:1212) Caused by: java.lang.ArrayIndexOutOfBoundsException: 1 at org.eclipse.jdt.internal.compiler.classfmt.MethodInfoWithParameterAnnotations.getParameterAnnotations(MethodInfoWithParameterAnnotations.java:24) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:434) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:565) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:333) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:719) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:699) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.accept(MatchLocator.java:307) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:138) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.resolve(ParameterizedTypeBinding.java:839) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:117) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveTypeFor(BinaryTypeBinding.java:903) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.availableFields(BinaryTypeBinding.java:215) at org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:227) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1580) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1040) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1081) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1213) 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) Root exception: java.lang.ArrayIndexOutOfBoundsException: 1 at org.eclipse.jdt.internal.compiler.classfmt.MethodInfoWithParameterAnnotations.getParameterAnnotations(MethodInfoWithParameterAnnotations.java:24) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethod(BinaryTypeBinding.java:434) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.createMethods(BinaryTypeBinding.java:565) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.cachePartsFrom(BinaryTypeBinding.java:333) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:719) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.createBinaryTypeFrom(LookupEnvironment.java:699) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.accept(MatchLocator.java:307) at org.eclipse.jdt.internal.compiler.lookup.LookupEnvironment.askForType(LookupEnvironment.java:102) at org.eclipse.jdt.internal.compiler.lookup.UnresolvedReferenceBinding.resolve(UnresolvedReferenceBinding.java:49) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:138) at org.eclipse.jdt.internal.compiler.lookup.ParameterizedTypeBinding.resolve(ParameterizedTypeBinding.java:839) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveType(BinaryTypeBinding.java:117) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.resolveTypeFor(BinaryTypeBinding.java:903) at org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding.availableFields(BinaryTypeBinding.java:215) at org.eclipse.jdt.internal.core.search.matching.ClassFileMatchLocator.locateMatches(ClassFileMatchLocator.java:227) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.process(MatchLocator.java:1580) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1040) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1081) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:1213) 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)That exception is not really tied to anything other than JDT, so best guess is to try to upgrade Eclipse, although I can imagine that it is somehow caused by the Maven plugin even though it is disabled for the project. This is another reason why I want to upgrade to 3.4.2…
Google did not help with that problem.
Best regards,
Robert
