| Re: [ide-dev] Some constructive criticism for Eclipse |
|
Hi Nikolay,
Thanks for contributing to Eclipse and sharing your experience and concerns. I've tried to give some concrete workarounds for your issues below. On 04/03/2016 10:26 PM, Nikolay Metchev wrote: It seems to me that most of your issues are related to PDE target-platforms. Target-platforms are a powerful but not much documented concept when developing plugins.So a few days I filed another bug thinking I would be a good citizen (https://bugs.eclipse.org/bugs/show_bug.cgi?id=490769). It immediately got closed as "NOT_ECLIPSE" and blame was attributed to Xerces. It transpired that Eclipse is using a 10 year old version of Xerces but moving to the latest version of Xerces doesn't address this issue. So being a developer I thought I would try and investigate what can be done about this. Initially I just browsed the code and concluded that Eclipse is indeed to blame because it has explicit code that overcomes limitations of Xerces in the org.eclipse.wst.xsd.core.internal.validation.eclipse.XSDMessageInfoHelper class. So naturally I thought I would try and see if I can get Eclipse dev environment set up to try and see if I can write some code to fix this issue. I spent roughly 4 hours and didn't get anywhere near to success. It seems the process has come along way with the introduction of this page: https://wiki.eclipse.org/Platform_UI/How_to_Contribute#Setting_up_your_SDK_for_code_contributions. However even after following the steps on there it still doesn't feel like it is quite correct and that I have missed something: That wiki page should for one thing talk about the fact that you need to install the correct version of JRE/JDK and what those versions are. It should also talk about Execution Environments because you need to set those up as well otherwise you get nowhere fast. The page should also discuss Bundle pools. This is something new and I am not quite sure what it is and how it works (more on this later). Anyway the Eclipse installer doesn't yet seem to have support for the setting up a dev environment for the web tools project which is probably another reason for my frustrations. So I ticked the JDT UI project instead. After the installer had completed I was left with a project which had 7 errors 4 of which I don't understand (see at the end). Also somehow the org.eclipse.jdt.launching.prefs file was modified on several of the projects without me doing anything (the org.eclipse.jdt.launching.PREF_STRICTLY_COMPATIBLE_JRE_NOT_AVAILABLE property was changed to warning). Searching for a page that describes how to set up a WTP for dev yields this horrifically out of date page that is useless: http://www.eclipse.org/webtools/community/tutorials/DevelopingWTP/DevelopingWTP.html I ignored all that and tried to get the wst xsd editor code checked out from git by pulling from https://git.eclipse.org/r/sourceediting/webtools.sourceediting and importing all the projects into their own working set. This of course didn't achieve what I really wanted as there were several projects that were only there for unit testing. After I removed those I was left 87 plugin project, 18016 errors and roughly 100 modified files. Not a good start. Most of the errors were that dependencies weren't being looked up somehow. I thought I would try and fix the org.eclipse.wst.xsd.core plugin as that contained the Class I was actually going to modify. That plugin seems to depend on other plugins which somehow weren't being resolved. so for example org.eclipse.core.runtime was quite happily being picked up from the Bundle pool (C:\Users\Nikolay\.p2\pool\plugins) but org.eclipse.wst.comon.uriresolver was showing up with a red cross even though that plugin is in exactly the same location. I managed to actually get that dependency working by checking out another git project (http://git.eclipse.org/gitroot/webtools-common/webtools.common.git) into its own Working set. This managed to resolve the org.eclipse.wst.comon.uriresolver project but still left org.eclipse.xsd unresolved, so I checked out (https://git.eclipse.org/r/xsd/org.eclipse.xsd) so now I am up to 137 project and the errors have gone down to 15712. This is where I got stuck. Things still weren't compiling because org.eclipse.wst.xml.core depends on org.apache.xerces and eclipse is refusing to pick up that dependency from the pool bundle, and I don't have a git repository I can check it out of. I am guessing that all my problems can be addressed. Probably the easiest would be for someone to write a wiki page explaining how to set all this up or to get Web tools support added to Oomph. Here is a way you could use it for this use-case: * Download a Neon M6 Java EE build (that contains webtools). This will be your target-platform. * In your Preferences > Plugin development > Target-Platforms; select this package as a target-platform. By the way, note that you could have other ways of defining a target platform, such as referencing some p2 repositories (very useful to develop against more recent builds, or if you need some source bundles that aren't in EPP packages) Then your IDE will allow you to use the plugins of this target-platform as dependencies. * Import the org.eclipse.wst.xsd bundle and other bundles you'd like to work with in your workspace You should be able to hack and test it without trouble. I believe we all fully agree with that.If people like me are getting ignored when submitting bugs and find it extremely hard to fix bugs themselves it feels like Eclipse is a lost cause and it's only a matter of time before it dies a death. Technically, many recent changes such as Oomph were designed to simplify this. However, it's still not quite successful according to your feedback. About comments being ignored, it's indeed frustrating. Most Eclipse committers have their own work and constraints and it's sometimes tricky to have them integrating discussions or reviews in their work. I have no good solution for that. The only hint I can give is that you comment on bugs on a regular basis (every 2 to 3 weeks) to make sure it's not forgotten. For example, JDT committers seem now much faster in reviewing patches than they were a few years ago (more staff, maybe a better workflow...); so just commenting on the bug might make some of them consider your patch now although it was ignored for 2.5 years. Those are errors with PDE API Tools and baseline.JDT UI Errors that don't make sense: Description Resource Path Location Type Invalid @since 3.1 tag on internalProcessOnCancel(Change); expecting @since 3.7 CompositeChange.java /org.eclipse.ltk.core.refactoring/src/org/eclipse/ltk/core/refactoring line 406 @since tag problem Invalid @since 3.1 tag on internalSetQueryFactory(IValidationCheckResultQueryFactory); expecting @since 3.7 RefactoringCore.java /org.eclipse.ltk.core.refactoring/src/org/eclipse/ltk/core/refactoring line 133 @since tag problem Missing @since tag on internalHandleException(Change, Throwable) CompositeChange.java /org.eclipse.ltk.core.refactoring/src/org/eclipse/ltk/core/refactoring line 365 @since tag problem The minor version should be incremented in version 3.7.0, since new APIs have been added since version 3.7.0 MANIFEST.MF /org.eclipse.ltk.core.refactoring/META-INF line 5 Version Numbering Problem The baseline is a bit like a target-platform, except that you reference the most recent version released of the project you're working on. Then PDE compares your current work with the last release and give hints about versioning and @since tags. Those errors can have several causes and workarounds: * Either you baseline is not correctly set (using a snapshot or milestone instead of a release) => Fix it to last release in Preferences > Plugin development > API Baselines * Or maybe the hints about wrong @since tags or version are right. Then you should consider make sure you are working with the HEAD commit of the plugin that seems erroneous (to get the latest version), or simply considering that those comments are right and apply the suggested change * Or, in project settings, turn the API Warning/Errors to ignore, but you may miss some interesting hints. HTH, |