Community
Participate
Working Groups
Created attachment 281690 [details] Sample project When debugging a project with library which doesn't have source code with ECD (Eclipse class decompiler) is installed, in earlier eclipse versions the class file editor is opened, when decompiler is configured as the default editor for class file the decompiled class is opened and the execution line is highlighted. But with latest eclipse versions this doesn't work. Instead a no source found editor is shown. I think this new behavior started with 2018-09. Attaching a sample project. Try to step into RMObjectBuilder constructor for example with ECD plugin installed.
Are we talking about this project? https://marketplace.eclipse.org/content/enhanced-class-decompiler And is this the right ticket? https://github.com/ecd-plugin/ecd/issues/69 And is this your problem too? Quote: I just did the clean Eclipse 2019-09 installation and added ECD to it. Even though the flag "Set Class Decompiler Viewer as the Default 'Java Class File' content type editor" is set looks it doesn't have any effect. Yes, I can go to "File Associations" and set Decompiler Viewer for both "*.class" and "*.class without the source" file types, and it works but only temporary till the next restart. After I restart Eclipse it sets the OOTB Class File Viewer for both *.class types. Any idea how to fix it? I tried all possible combinations, created new workspaces and etc. - nothing helped. the same issue happened with the older Eclipse versions as well It is annoying to manually associate types each time I restarted Eclipse.
Do you see errors in the log, and do they look like https://github.com/ecd-plugin/ecd/issues/59? This would be bug 543073.
Gayan: it would save some time if you would post the link to your original bug report here: https://github.com/ecd-plugin/ecd/issues/58. Reading this, I believe the launch configuration could be the problem. If we don't even "see" the class file on the class path that is defined in this launch config, we might not try the source lookup for that class (because we can't find it on classpath). Please attach also you launch configuration.
Created attachment 281704 [details] Launch Configurtion
Attached the launch configuration and yes this is the original bug i reported https://github.com/ecd-plugin/ecd/issues/58
I get this problem when running with java 1.8 as well.
No errors in the error log either.
Any updates on this issue ?
any update on this issue ? Does this happens because of the m2e source provider implementation?
(In reply to Gayan Perera from comment #9) > any update on this issue ? Does this happens because of the m2e source > provider implementation? I don't use m2e. Please try whether it works without that provider.
I did some more testing after my last comments. Seems like this happens only for maven projects. So it means the m2e source provider is the problem here. Any tips on fixing this ?
(In reply to Gayan Perera from comment #11) > I did some more testing after my last comments. Seems like this happens only > for maven projects. So it means the m2e source provider is the problem here. > Any tips on fixing this ? Remove the source provider.
How to remove the source provider from the launcher ?
(In reply to Gayan Perera from comment #13) > How to remove the source provider from the launcher ? Can you try to debug the Eclipse IDE to find out what's wrong?
I did some days back. But i will do it again and post my findings. Specially whats happens when the m2e source provider is used.
When the external libraries are loaded as system dependencies the decompiler works. So seems like the m2e source lookup resolver doesn't find the classes when they are added as reference libraries.
@Gayan Can you provide exact steps to reproduce the problem, starting from clean/fresh eclipse install and empty workspace?
1. Start Eclipse 2. Install EDC plugin from marketplace 3. Extract the project workspace_updated.zip and import. 4. Debug the Application.java line at 21 and try to step into RMObjectBuilder class constructor. 5. The decompiler is not used decompile and show the source code with the breakpoint execution line.
Created attachment 281790 [details] workspace_updated.zip
Also adding a breakpoint in the decompiled class sun.misc.Launcher.AppClassLoader.getPermissions(CodeSource) will hit the breakpoint, but the execution point is not highlighted in the decompiled source. instead the no source found page is shown.
The previous comment is when you are running with a jdk which doesn't have source code attached.
What if the maven source lookup provides away to disable that ?
Or should we enable the maven sourcelookup only if we have the maven dependency container in the launcher classpath ?
(In reply to Gayan Perera from comment #23) > Or should we enable the maven sourcelookup only if we have the maven > dependency container in the launcher classpath ? So if I understand correctly, the Maven source lookup is used before the decompiler (which is a good thing), but returns erroneous result that abort the sourcelookup process and skips the ECD step? If so, we should investigate what makes the whole sourcelookup abort instead of continuing to next provider. The Maven source lookup is much better than decompiler and can work for many jars, even not the one in Maven container, so we should try to keep it even for non-Maven container as it can still deliver a lot of value there.
The MavenSourcePathProvider just resolve IRuntimeClasspathEntry instances. I think its something to do with not running the default resolution part of the StandardSourcePathProvider.
The problem is with the org.eclipse.m2e.jdt.internal.launch.MavenSourcePathProvider.addProjectEntries(Set<IRuntimeClasspathEntry>, IPath, int, String, ILaunchConfiguration, IProgressMonitor, int) method. When i change to use the super implementation everything works fine with ECD.
@Mickael Do you have any suggestion how to fix this ? Should we remove this method so that the super implementation will handle the source lookup ?
(In reply to Gayan Perera from comment #27) > @Mickael Do you have any suggestion how to fix this ? Should we remove this > method so that the super implementation will handle the source lookup ? Sorry, I don't know the details of these pieces of code to give hints at the moment. Before talking about code, we need to better understand the workflow. It's still unclear to me what does m2e change that prevent ECD (or other source lookups) from being invoked. I imagine the source lookup mechanism should try multiple providers until it finds a good one, is it the case? If so, why is it aborted after m2e runs?
(In reply to Mickael Istria from comment #28) > (In reply to Gayan Perera from comment #27) > > @Mickael Do you have any suggestion how to fix this ? Should we remove this > > method so that the super implementation will handle the source lookup ? > > Sorry, I don't know the details of these pieces of code to give hints at the > moment. > Before talking about code, we need to better understand the workflow. It's > still unclear to me what does m2e change that prevent ECD (or other source > lookups) from being invoked. I imagine the source lookup mechanism should > try multiple providers until it finds a good one, is it the case? If so, why > is it aborted after m2e runs? I think standard provider code just populate the source classpath with the same library. So if the class source can be found the .class file is opened. Then ECD kicks in to open that file decompile it and render the debug pointer. But with Maven source path provider the entire classpath is not processed as it seems. So my suspection is that is the problem. Who know this workflow and code better ?
(In reply to Gayan Perera from comment #29) > I think standard provider code just populate the source classpath with the > same library. So if the class source can be found the .class file is opened. > Then ECD kicks in to open that file decompile it and render the debug > pointer. But with Maven source path provider the entire classpath is not > processed as it seems. So my suspection is that is the problem. I think you're right and the implementation of MavenSourcePathProvider.getProjectEntries() is too greedy and adds some faulty "resolved" elements. However, I have no clear idea of what would be the ideal behavior here, as their is not contract explicited for this method. This would require to audit the code.
(In reply to Mickael Istria from comment #30) > (In reply to Gayan Perera from comment #29) > > I think standard provider code just populate the source classpath with the > > same library. So if the class source can be found the .class file is opened. > > Then ECD kicks in to open that file decompile it and render the debug > > pointer. But with Maven source path provider the entire classpath is not > > processed as it seems. So my suspection is that is the problem. > > I think you're right and the implementation of > MavenSourcePathProvider.getProjectEntries() is too greedy and adds some > faulty "resolved" elements. However, I have no clear idea of what would be > the ideal behavior here, as their is not contract explicited for this method. > This would require to audit the code. Do you know any friends who can help in finding out the behavior that should be here ? For now i can run my setup with a patched version, but its good if we can fix this soon.
I suggest you submit a patch to Gerrit removing totally the faulty method, and we'll see what the test results are. If they don't spot any regression and no-one has objections, we'll just merge the stuff.
New Gerrit change created: https://git.eclipse.org/r/157785
(In reply to Mickael Istria from comment #32) > I suggest you submit a patch to Gerrit removing totally the faulty method, > and we'll see what the test results are. If they don't spot any regression > and no-one has objections, we'll just merge the stuff. Seems like the build is successful on my gerrit patch. No test failures.
I was alerted to this issue yesterday. In certain cases, the correct editor opens and debugging works as expected. For example, I use PrimeFaces 5.1. For PF components, the source is opened correctly. But, for jsf-api 2.1.4, it opens as a Java file. From the stacktrace, I right-click the frame and select "Source Lookup Info". PrimeFaces: Code Location: C:\Users\brian\workspace\eclipse\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\pm\WEB-INF\lib\primefaces-5.1.6.jar GAV: [org.primefaces:primefaces:5.1.6] Java project: <not-implemented> Source container: empty JSF Code Location: C:\Users\brian\workspace\eclipse\.metadata\.plugins\org.eclipse.wst.server.core\tmp0\wtpwebapps\pm\WEB-INF\lib\jsf-api-2.1.4.jar GAV: [com.sun.faces:jsf-api:2.1.4] Java project: <not-implemented> Source container: ExternalArchiveSourceContainer C:\Users\brian\.m2\repository\com\sun\faces\jsf-api\2.1.4\jsf-api-2.1.4-sources.jar
Gerrit change https://git.eclipse.org/r/157785 was merged to [master]. Commit: http://git.eclipse.org/c/m2e/m2e-core.git/commit/?id=7deeca873433e5d2bcf7756edb60da3194b0df86
Thanks Gayan!
Your welcome Mickael
@Brian you can try with nighties which will have the this fix and see if it works. This problem only happens if your project is a maven project.
I tested the sample project with https://download.eclipse.org/technology/m2e/snapshots/1.15.0/latest/ I have ECD installed, set the class without sources associations to use ECD manually, When stepping into the RMObjectBuilder constructor, the decompiled source doesn't show up. I have my doubts on the validity of the fix. Seems to me this is more an issue of compatibility between ECD and latest JDT versions.
See the comment at https://bugs.eclipse.org/bugs/show_bug.cgi?id=560392#c47. This source lookup is causing JDT debug variable resolution. My Fix for m2e actually fixed it as well. Do you see any side effects of my fix ? i don't think there is any problem with ECD. Its working fine if the source locator lookup the element without returning null like the m2e source locator does.
Sorry seems like the Lambda issue is still there with the fix i have given even. But seems like the maven source locator has some serious issues.
(In reply to Gayan Perera from comment #42) > Sorry seems like the Lambda issue is still there with the fix i have given > even. But seems like the maven source locator has some serious issues. Please open new tickets for each one of the issues you noticed.
reported https://bugs.eclipse.org/bugs/show_bug.cgi?id=561554
I think the change here causes bug 561476. Maybe we'll have to revert it (especially if it doesn't fix the initial issue).
We will most likely revert the change soon.
New Gerrit change created: https://git.eclipse.org/r/160262
Gerrit change https://git.eclipse.org/r/160262 was merged to [master]. Commit: http://git.eclipse.org/c/m2e/m2e-core.git/commit/?id=1f82b4133a0ac992d90689df6914e54f45e37945
@Fred @Igor @Mickael when looking more into the code i found the following. The main problem i cannot go into the decompiled class it the IDE doesn't find a java element for the given class. The reason is the org.eclipse.m2e.jdt.internal.launch.MavenRuntimeClasspathProvider.computeUnresolvedClasspath(ILaunchConfiguration) doesn't contain the java libs i have added in the project. The StandardClasspathProvider handles this by adding a newDefaultProjectClassPathEntry for the project. replace the newProjectRuntimeClasspathEntry at MavenRuntimeClasspathProvider.computeUnresolvedClasspath with newDefaultProjectClassPathEntry actually resolves the problem for non modular projects. So i was thinking what if we find all the java reference libraries from computeUnresolvedRuntimeDependencies and add the ARCHIVE entries into the return value. What do you guys think ? I want to make things right this time :)
(In reply to Gayan Perera from comment #49) > replace the > newProjectRuntimeClasspathEntry at > MavenRuntimeClasspathProvider.computeUnresolvedClasspath with > newDefaultProjectClassPathEntry How are the returned value different? I would expect JavaRuntime.newProjectRuntimeClasspathEntry to be reliable here (the name totally matches what we expect). Could it be this methods that needs a fix?
@Mickael i can that tonight and get back to you. What about my second alternative using the archive entries ?
(In reply to Gayan Perera from comment #51) > @Mickael i can that tonight and get back to you. What about my second > alternative using the archive entries ? Wouldn't that fail in case classpath contains a folder (which itself contains .class files)? I'm not sure I fully understand enough about the issue though (the fact that I merged a breaking commit is an example of my lack of understanding here). Can you please re-explain (with simplest example) what's wrong with the current code? Ie what does it return that it shouldn't return or the other way round, and in which case, according to specification of IRuntimeClasspathProvider.computeUnresolvedClasspath(...) ?
Created attachment 282313 [details] simple project @Mickael, here is a simple project based on some sample code from the other bug we had. here in the bug561476.main project i have a jar file dependency to /bug561476.main/lib/bug561476.library-0.0.1-SNAPSHOT.jar. You need to have ECD installed in your workspace to test this. Now if you open bug561476.library.Library.ping() in ECD and add a break point in that method and debug your code, you will see that in debug mode the class file Library is not decompiled and opened. Instead it shows "source not found". This is the problem. This happens even if you add the classes folder into the classpath as well.
any update @Mickael, @Fred or @Igor
@Fred @Igor @Mickael any tips on how we should move this issue forward. I can also include folders and archives into classpath on what @Mickael brought up earlier on my suggested solution. I bit hesitant to change JavaRuntime method we use here since it can have adverse effect on other areas unless someone can confirm its but in its implementation.
(In reply to Gayan Perera from comment #55) > @Fred @Igor @Mickael any tips on how we should move this issue forward. I > can also include folders and archives into classpath on what @Mickael > brought up earlier on my suggested solution. I bit hesitant to change > JavaRuntime method we use here since it can have adverse effect on other > areas unless someone can confirm its but in its implementation. What I don't get is that classpath resolution seems working fine: for a .class that doesn't have an associated .java file, the class editor is shown and shows the right class. I'm wondering why specifically this would be an m2e issue. Isn't it ECD relying on unrealistic assumptions about project settings?
@Mickael did you try my small example ? Did the ping() method opened in the class file editor when you didn’t had ECD installed instead of showing the “no source found “ message ?
Created attachment 282333 [details] Screenshot of class file editor > did you try my small example ? Did the ping() method opened in the class file editor when you didn’t had ECD installed instead of showing the “no source found “ message ? Yes, here is the editor I see (without ECD installed). It's the regular editor I'd expect in that case, the debugger sending information about the .class file being referenced. At this point, the sent reference is entirely correct and it should be up to ECD to deal with it. I don't get what and why m2e should change here as the value it returns are very accurate.
@Mickael, Opening the class file works fine. Try to debug the code by putting a break point at "new Library().ping();" in the main class bug561476.main.Main. No when the debugger hits that line try to step into the ping() method of bug561476.library.Library.ping(). Then you will see that the classfile editor is not opened, instead the no source found editor is open. I will attach a screenshot
Created attachment 282342 [details] No Source Found Editor
(In reply to Gayan Perera from comment #59) > @Mickael, Opening the class file works fine. Try to debug the code by > putting a break point at "new Library().ping();" in the main class > bug561476.main.Main. > > No when the debugger hits that line try to step into the ping() method of > bug561476.library.Library.ping(). > > Then you will see that the classfile editor is not opened, instead the no > source found editor is open. I will attach a screenshot OK, I see, I was using a previous version of m2e.
Mu suggestion at https://bugs.eclipse.org/bugs/show_bug.cgi?id=559797#c49 does support class folders as well.
(In reply to Gayan Perera from comment #59) > @Mickael, Opening the class file works fine. Try to debug the code by > putting a break point at "new Library().ping();" in the main class > bug561476.main.Main. > > No when the debugger hits that line try to step into the ping() method of > bug561476.library.Library.ping(). > > Then you will see that the classfile editor is not opened, instead the no > source found editor is open. I will attach a screenshot I am using I20200404-1800 and 1.15 m2e with 3.1.1 ECD. I debugged Main.java and by stepping in it went to the class loader and then to bug561476.library.Library.ping(). What am I missing?
(In reply to Sarika Sinha from comment #63) > I am using I20200404-1800 and 1.15 m2e with 3.1.1 ECD. > [...] > What am I missing? Sorry, forgot to mention: you need to use m2e snapshot from https://download.eclipse.org/technology/m2e/snapshots/1.16.0/latest/ . 1.15.0 contains a fix for it ( https://git.eclipse.org/c/m2e/m2e-core.git/commit/?id=7deeca873433e5d2bcf7756edb60da3194b0df86 ) which caused bug 561554 so it was reverted in 1.16 snapshots.
(In reply to Mickael Istria from comment #64) > (In reply to Sarika Sinha from comment #63) > > I am using I20200404-1800 and 1.15 m2e with 3.1.1 ECD. > > [...] > > What am I missing? > > Sorry, forgot to mention: you need to use m2e snapshot from > https://download.eclipse.org/technology/m2e/snapshots/1.16.0/latest/ . > 1.15.0 contains a fix for it ( > https://git.eclipse.org/c/m2e/m2e-core.git/commit/ > ?id=7deeca873433e5d2bcf7756edb60da3194b0df86 ) which caused bug 561554 so it > was reverted in 1.16 snapshots. Thanks, with 1.16 latest I was able to get the "Source Not Found" Editor if "Advanced Source Lookup" was switched off. It works fine and opens Library.java if I select the "Advanced Source Lookup" under Preferences->Java->Debug. Can you what is the option in your workspace and does the toggling impact?
I have advance source lookup enabled. But it still fails. Are you sure you are running the app as a maven project rather than just a JDT project.
(In reply to Gayan Perera from comment #66) > I have advance source lookup enabled. But it still fails. Are you sure you > are running the app as a maven project rather than just a JDT project. Have you done the source attachment for the Referenced Library? I see that without that attachment I get the "Source Not Found" editor but after adding I was bale to proceed.
Created attachment 282371 [details] Source attachment
I think the purpose of this bus is to open the class without source attachment in the class editor. Why we need to do that is so that the class decompiler can pick up the class and decompile in such a situation. When the debugger ask to open the file in class file editor then the ECD can be used to open the class file if the editor for class files is set to ECD editor.
@Sarika seems like you are adding the binary file as a source attachment right ?
(In reply to Gayan Perera from comment #70) > @Sarika seems like you are adding the binary file as a source attachment > right ? Yes, the jar is attached as source which gets Decompiled by ECD and when we step in it gets into the decompiled class. I don't have corresponding java file in the workspace.
My findings are that if the maven source lookup is used these binaries are not added to the source lookup path. But the default source lookup which used for non maven projects these libraries are added in to source lookup path. My suggestion is we do the same in the maven source lookup as well.
(In reply to Gayan Perera from comment #72) > My findings are that if the maven source lookup is used these binaries are > not added to the source lookup path. But the default source lookup which > used for non maven projects these libraries are added in to source lookup > path. My suggestion is we do the same in the maven source lookup as well. Concretely, what I don't get is why Maven Source lookup even participates and returns something here, if it doesn't have anything interesting to answer... Shouldn't the behavior be delegated to JDT or other instead? If possible, I'd rather see m2e do less (and avoid returning erroneous values) instead of adding more behavior into it.
(In reply to Mickael Istria from comment #73) > (In reply to Gayan Perera from comment #72) > > My findings are that if the maven source lookup is used these binaries are > > not added to the source lookup path. But the default source lookup which > > used for non maven projects these libraries are added in to source lookup > > path. My suggestion is we do the same in the maven source lookup as well. > > Concretely, what I don't get is why Maven Source lookup even participates > and returns something here, if it doesn't have anything interesting to > answer... Shouldn't the behavior be delegated to JDT or other instead? > If possible, I'd rather see m2e do less (and avoid returning erroneous > values) instead of adding more behavior into it. Well i would say maven source lookup is correct here, it does return the project sources and JRE and M2 Container entries. What is miss is the other type of libraries (other than maven container) that a JDT project can have. There is the problem with maven source lookup. May be maven should add the M2 container entries on to what base source lookup provides. May be i can investigate and see if you all think that's a good approach.
Yes, Problem is not in classpath entries. Problem is the inability of the existing SourceContainers to find the location of this file. The fix should be in this direction.
I see that there is a difference in the source container for the project when JDT and Maven JDT project is used to launch the application. In JDT scenario the org.eclipse.jdt.launching.JavaRuntime.newDefaultProjectClasspathEntry is used. This cause down the like to create a different source container to be used which is capable of resolving the class files in this example. But for maven it uses org.eclipse.jdt.launching.JavaRuntime.newProjectRuntimeClasspathEntry which cause a another type of source container which doesn't resolve the class files we want.
Any update @Mickael and @Sarika ?
(In reply to Gayan Perera from comment #77) > Any update @Mickael and @Sarika ? To be honest, I'm totally uncertain about this piece of code, so it's hard for me to judge. So if you have another idea, please submit a patch (as a different Gerrit review if it's a totally different approach) and maybe the code will help to figure out the best proposals.
Hello, Would you all mind taking a look at 541263 if you aren't already aware of it? I was lead to this issue from there. I feel like it might present what I believe to be the same issue from a different perspective. Thanks.
@Brian if don’
(In reply to Gayan Perera from comment #80) > @Brian if don’ @Brain this comment was a mistake. But will test the code in the mentioned bug with my working poc fix. If everything is good will push a new gerrit since my new fix is totally different than previous
@Brian looking at you issue, seems like its little bit different, because in your case the maven find source jar and expose that source outside the javaproject's context. But if you attach the source code to the jar file everything works fine. I think that bug requires a different fix. By the way @Mickael why does m2e just download a source jar file and expose it outside java project. because doing that i don't see any benefit since you can't do any evaluations on that open source file. This bug is to handle when there are not source cannot be found. that is when neither source jar can be found for the jar file from the MavenSourceContainerResolver. which caused to return null in turns shows the "No Source Found" editor.
(In reply to Gayan Perera from comment #82) > By the way @Mickael why does m2e just download a source jar file and expose > it outside java project. because doing that i don't see any benefit since > you can't do any evaluations on that open source file. You mean the m2e source lookup? I don't know for sure, but as I understand it it's just a "missing step" to implement. Indeed, when a source jar is downloaded, it would be desired that m2e modifies all the Maven classpath containers to associate the .jar file with its source and then tries to reopen related class or "source not found" editors. If it doesn't do that, I imagine the main reason is just that no-one implemented it so far. > This bug is to handle when there are not source cannot be found. that is > when neither source jar can be found for the jar file from the > MavenSourceContainerResolver. which caused to return null in turns shows the > "No Source Found" editor. Who is responsible of opening the editor here? Is it JDT or m2e? If it's JDT, I would assume that if provided a class that has no source, it could try to show the .class file in the Class editor if available. And that brings me to other fields about ECD: why isn't it "overriding" the Source Not Found editor?
@Mickael we cannot do that because org.eclipse.debug.internal.ui.sourcelookup.SourceLookupFacility.lookup(Object, ISourceLocator, boolean) line 342 sourceElement is null. Without a ClassFile as a the sourceElement the ECD doesn't have to work on anything.
@Mickael and one thing not is m2e is that, it doesn't try to download the source artifact. it will only attache if the artifact is available.
New Gerrit change created: https://git.eclipse.org/r/160733
@Mikael @Igor any comments on the patch ?
IMO, this seems more and more like a bug in ECD. Why doesn't it also show up for the "Source not found" case?
(In reply to Mickael Istria from comment #88) > IMO, this seems more and more like a bug in ECD. > Why doesn't it also show up for the "Source not found" case? Please check https://bugs.eclipse.org/bugs/show_bug.cgi?id=559797#c82 and https://bugs.eclipse.org/bugs/show_bug.cgi?id=559797#c84 I have answered why we cannot open the classfile with ECD for this dummy editor.
New Gerrit change created: https://git.eclipse.org/r/160924
@Mickael any update on this bug ?
Anyone @Mickael @Igo @Fred any input on the patch ?
I tried again with m2e from master (so no new patch applied), having ECD installed, the class file associations configured to use ECD by default. I - imported bug561476.main as a Maven project from https://bugs.eclipse.org/bugs/attachment.cgi?id=282313. - When I opened Library.ping(), the Fernflower decompiled class showed up. - I closed that Library.class tab. - Proceeded to debug bug561476.main's Main class, stepped into Library.ping(), the Fernflower decompiled class showed up. - I then imported bug561476.library as a Maven project - When I opened Library.ping() from bug561476.main's Main class, the Fernflower decompiled class still showed up. - Debugged bug561476.main's Main class, stepped into Library.ping(), the actual Library.java source from bug561476.library opened. So, it seems to me it's working as expected, on my machine (MacOS 10.15.3) at least, without any modifications.
Sure @Fred i will try tonight with latest master branch.
sorry, disregard my last comment, turn out my master branch was not up-to-date with the canonical repo. I can reproduce the issue. Will check with the patch applied then
@Fred any update on this patch?
Any updates on this issue? can we release this with 4.16?
Corrected the commit message as well
Any one who can help me to review this so that we can make it to 4.16. Right now i have to patch eclipse with these changes in my setup always.
Any update on this issue? Some review comments are appreciated :). @Mickael @Fred @Igor
Gerrit change https://git.eclipse.org/r/160733 was merged to [master]. Commit: http://git.eclipse.org/c/m2e/m2e-core.git/commit/?id=971f71643d0d7de43975ef3aa5e8c87a466bb113
Moved to https://github.com/eclipse-m2e/m2e-core/issues/
