Community
Participate
Working Groups
Build Identifier: After I spend a lot of effort to get JDT out of Sigasi's RCP application, I now have problems with users installing the plugin in an Eclipse where JDT is installed too. We currently offer an update site with the Sigasi plugins and also all plugins our plugins depend on. These include EMF and Xtext. Because we do not depend on JDT, the update site only contains a subset of the Xtext plugins (the ones that do not depend on JDT). This way if a user wants to install our plugins, JDT is not installed. However, if a user has JDT, installed, Xtext tries to load extra plugins which are not installed. As a result our plugins can not be started. (http://www.sigasi.com/forum/error-activating-plug-sigasi-20): java.lang.NoClassDefFoundError: org/eclipse/xtext/common/types/ui/notification/TypeResourceUnloader at org.eclipse.xtext.ui.shared.internal.SharedModuleWithJdt.configure(SharedModuleWithJdt.java:33) As a workaround I have added the org.eclipse.xtext.ui feature to the update site. However, this has the unwanted effect that Eclipse will greedily install JDT when our plugin is installed (http://www.eclipse.org/forums/index.php?t=rview&goto=691039#msg_691039). My guess for the fix is that the methods that detect whether to activate JDT-functionality, should also take into account whether the corresponding (optional) Xtext plugins are actually available. Reproducible: Always
Why don't you provide the complete Xtext UI Feature together with your features?
(In reply to comment #1) > Why don't you provide the complete Xtext UI Feature together with your > features? Sorry, that was too fast. Would it work for you if you provide an optional feature "VHDL for IDE for Java Developers" which would install the complete Xtext UI feature? Otherwise we'd have to check for all the optional dependencies explicitly which is kind of errorprone and cumbersome.
Hi Sebastian, that is the workaround I described. The update site now contains the org.eclipse.xtext.ui feature. But this has the disadvantage that if you install the plugin in an Eclipse without JDT, JDT will be installed too (http://www.eclipse.org/forums/index.php?t=rview&goto=691039#msg_691039). I'm also afraid, that if a user installs JDT in our RCP version. She will also run into the NoClassDefFoundError. I don't know how the optional dependencies work, but sounds incorrect to assert their presence. Hendrik.
Hi, We've also run into this problem in our RCP application... Optimal we don't want any JDT dependency at all in the application, but at the moment we have dependency to JDT Core (since some other external frameworks we utilize requires it). And here is the dilemma; since the JDT Core is present the Xtext framework will activate the whole JDT-functionality, resulting in a dependency flow in our RCP to require additional jdt dependencies. The main problem; JDT UI will be required! This is not an option in our RCP, we must not have that dependency included. Conclusion: We want to use Xtext without any java integration functionality and without any required dependency to JDT UI. I partly understand the design idea to detect whether or not the jdt core is present in runtime in order to decide if the JDT-functionality should be activated. However, as Hendrik previously faintly outlined, the detection as it is today seems too "simple". In my opinion there should be a more "static" way of ensuring JDT-functionality activation/disabling. Would it maybe be a possible way to make use of an Extension Point to be able to declare this activation/disabling? An advantage with this approach seems to me that one would get a more "safe/robust" application at the end, since the activated/disabled functionality is not only based on what the end-user has installed in his environment, but on an active choice by the developer. Regards, Joachim
I fully agree with the previous speakers. Our application have dependencies to jdt -core, but we certainly don't want to ship jdt-ui to our customers.
Preliminary scheduled for Kepler. A patch is most welcome.
I disagree with the extension approach. You could have conflicting settings for different Xtext plugins. And in my option it is up to the end user to decide whether she installs the JDT (UI) plugins or not. org.eclipse.xtext.ui.shared.internal.Activator currently only checks for JavaCore.class in isJavaEnabled(). Wouldn't the problem be solved if we added a few more checks for a class in following plugins too? * org.eclipse.jdt.ui (org.eclipse.jdt.ui.JavaUI.class?) * org.eclipse.xtext.ui.shared any other jdt plugins that Xtext depends on JDT mode?
There's probably a dependency to jdt.debug somewhere, but I'm not completely sure out of my head.
Created attachment 229165 [details] Extended isJavaEnabled test test that not only org.eclipse.jdt.core but also org.eclipse.jdt.debug, org.eclipse.jdt.ui and org.eclipse.xtext.common.types.ui are available before enabling JDT
Ok, there might be circumstances I have not forseen with an extension approach. I think you guys have a better knowledge for how the framework is to be used in a wider perspective. However, the other solution as Hendrik proposed should be OK for us to solve our problem! I.e. the solution that the isJavaEnabled() would have a few more checks added for classes in additional plugins, especially the org.eclipse.jdt.ui (org.eclipse.jdt.ui.JavaUI.class). Would appreciate a lot if such a change could be implemented as soon as possible!
Pushed to review
Requested via bug 522520. -M.
