Community
Participate
Working Groups
To use the WikiText MarkupViewer in a RCP application is necessary to include org.eclipse.ui.ide. Is it possible to avoid the dependency? It would be helpful to be able to use the viewer with a simple editor at least to avoid loading so many eclipse plug-ins in a RCP application.
Thanks for the bug. What parts of WikiText would you like to use in your RCP app? Some components of WikiText such as the source editor use the org.eclipse.ui.ide plug-in dependency.
Ideally a formatted text viewer without using SWT.Browser and editor that could be very simple but without the org.eclipse.ui.ide dependency. I'm trying to reduce dependencies too much ? :) I need a viewer I can embed in any dialog to show the formatted text and with the option to edit it. I have been testing WikiText to convert from wiki markup languages to HTML and is great. Now I'm using SWT.Text as editor and SWT.Browser to render.
It's probably feasible to have a text viewer without the ide dependency (see org.eclipse.mylyn.wikitext.ui.viewer.MarkupViewer). It may be difficult to do for the file-based editor, since it depends on org.eclipse.ui.editors which in turn depends on the ide bundle. It should be possible to create your own editor however using org.eclipse.mylyn.internal.wikitext.ui.editor.MarkupProjectionViewer without this dependency.
After some investigation here are the key features provided by the ide dependency that are used by the markup viewer: * hyperlink detector registry * preferences integration ** hyperlink detector enablement ** tab width ** hyperlink * spell check Other features are used by the ide dependency specifically for the markup file editor: * TextEditor * TextFileDocumentProvider * various actions From what I can see it would be relatively trivial to move the file editor into an ide-specific plug-in. The editor-specific dependencies are internal (not API) and thus easy to change. The dependencies used by the markup viewer are tougher to change without loss of functionality or API breakage. What is your objection to an org.eclipse.ui.ide dependency? Is it possible to achieve what you need by using *Capabilities* to disable various UI elements such as menus, wizards, preference pages, etc?
David, thank you for the investigation. > What is your objection to an org.eclipse.ui.ide dependency? Is it possible to > achieve what you need by using *Capabilities* to disable various UI elements > such as menus, wizards, preference pages, etc? The main objection is that my Eclipse RCP application is polluted with menus, toolbars,views when the IDE plug-ins are added. At least that is the visual consequence.
Juliano, though I haven't tried them, new for Eclipse 3.5 is "Capabilities":http://wiki.eclipse.org/Galileo_Capabilities, which are specifically designed to eliminate such visual clutter. I recommend taking a look to see if they'll solve the issue. Splitting out the IDE dependency is feasible for WikiText, though I would prefer to leave it until after Mylyn 3.2 due to the API-breaking nature of the changes that would be required.
related: bug 293066
I've got a candidate solution to this problem that reduces the org.eclipse.mylyn.wikitext.ui dependencies to the following: org.eclipse.mylyn.wikitext.core, org.eclipse.core.runtime, org.eclipse.jface.text, org.eclipse.ui, org.eclipse.ui.editors, org.eclipse.ui.workbench.texteditor, org.eclipse.ui.views, org.eclipse.core.expressions, org.eclipse.core.resources, org.eclipse.help, How does that look for an RCP application?
Mik, I'd like to create a new wikitext bundle org.eclipse.mylyn.wikitext.ide.ui The plan is to move MarkupEditor and a few other classes there from org.eclipse.mylyn.wikitext.ui. This will not create API breakage, however it will move a few internal classes, editor-specific actions and menus, and the property page that enables the WikiText nature on projects. With this change the new bundle will be added to the org.eclipse.mylyn.wikitext feature. This should allow users to use both Mylyn WikiText and Mylyn in RCP applications without having any IDE dependencies.
To what extend would that change eliminate dependencies from org.eclipse.mylyn.wikitext.ui? Wouldn't it be feasible to use capabilities to disable the WikiText contributions instead of moving them into a separate bundle?
(In reply to comment #10) > To what extend would that change eliminate dependencies from > org.eclipse.mylyn.wikitext.ui? org.eclipse.mylyn.wikitext.ui would no longer have a bundle dependency on org.eclipse.ui.ide > Wouldn't it be feasible to use capabilities to > disable the WikiText contributions instead of moving them into a separate > bundle? Yes however the goal is to make it easy to consume Mylyn WikiText APIs in RCP applications without having a dependency on the org.eclipse.ui.ide bundle. In my opinion it's not reasonable to expect RCP applications to include the Eclipse IDE bundle. Using capabilities to disable contributions made by org.eclipse.ui.ide adds significant learning overhead and effort.
(In reply to comment #11) > (In reply to comment #10) > > To what extend would that change eliminate dependencies from > > org.eclipse.mylyn.wikitext.ui? > > org.eclipse.mylyn.wikitext.ui would no longer have a bundle dependency on > org.eclipse.ui.ide I am not sure I understand what that achieves as long as there is a dependency on org.eclipse.ui.editors which has a transitive dependency on org.eclipse.ui.ide. How does the proposed change help RCP developers in practice?
(In reply to comment #12) > I am not sure I understand what that achieves as long as there is a dependency > on org.eclipse.ui.editors which has a transitive dependency on org.eclipse.ui.ide. Well now I have egg on my face :) I missed that dependency the second time around. It goes to show that leaving issues for too long can be costly. Thanks for pointing this out Steffen. To really make this work we'd have to split out all of the editor-specific components. We could leave in MarkupSourceViewer however to do so we'd basically have to make a copy of some platform code such as TextSourceViewerConfiguration. In doing so we'd avoid compile-time dependencies but still have dependencies on various IDE preferences, such as tab width, as described in comment #4. What we're left with is that by splitting out IDE components into a separate bundle we'd be left with very little functionality in the org.eclipse.mylyn.wikitext.ui bundle: some actions, context menus and a source viewer that is good for markup display purposes only. It's a lot of work for very little gain. The org.eclipse.mylyn.wikitext.*core bundles can easily be used in an RCP application without any dependencies on IDE bundles. Juliano, can you state your use case? I'd like to hear from you how you intend on using WikiText in your RCP app, and how this dependency issue affects your application. Also have you tried using Capabilities to disable specific UI contributions made by the IDE bundle? A better understanding of the issues you face will help us to come up with the best possible solution.
Hi David, thank you for the effort to try to solve this problem. What I wanted to do with WikiText is to add a "add note" feature where users can type formatted text and include some images if possible. I don't need a complex source editor, it could be a simple text editor with some formatting buttons. Using SWT.Browser to render is ok for me. I don't want to load my RCP application with bundles that are not required for performance reasons. Do you think disabling the UI elements is a good solution and the performance impact is low? I didn't try the Capabilities workaround.
(In reply to comment #14) > What I wanted to do with WikiText is to add a "add note" feature where users > can type formatted text and include some images if possible. I don't need a > complex source editor, it could be a simple text editor with some formatting > buttons. Using SWT.Browser to render is ok for me. @MarkupSourceViewer@ would be the WikiText class that provides the features that you're looking for. Unfortunately it does rely on the org.eclipse.ui.editors plug-in for things like tab-width, spell check, etc. > I don't want to load my RCP application with bundles that are not required for > performance reasons. As with all things performance it's probably best to try it out and see if it does make a performance impact. You may find that the impact is minimal. > Do you think disabling the UI elements is a good solution > and the performance impact is low? I didn't try the Capabilities workaround. At this point I recommend trying capabilities. Capabilities are specifically designed to address the issue of disabling targeted UI contributions. Please try using Capabilities to disable the ide UI contributions and provide feedback on this bug. You may find the solution fits your needs perfectly. If not, we'll have a much better idea as to how to move forward.
*** Bug 336324 has been marked as a duplicate of this bug. ***
Created attachment 188470 [details] Patch to remove dependency on o.e.ui.ide The code in this patch with make the dependency on org.eclipse.ui.ide optional and only use the IDE feature (in MarkupHyperlinkDetector) if the mentioned bundle is present. Should help somewhat.
(In reply to comment #17) > Created attachment 188470 [details] > Patch to remove dependency on o.e.ui.ide To be precise. It only removes the dependency from o.e.m.wikitext.ui. There is still some work to be done.
Thanks for your contribution. Note that there is a transitive dependency to @org.eclipse.ui.ide@ from @org.eclipse.ui.editors@. Until that problem is fixed, there's not much we can do here. Please reopen this bug if you have any ideas.
