Community
Participate
Working Groups
Build: Eclipse 3.0 I am building application on top of Eclipse, however we do not have any files because all the data must reside on the server. I would like to re-use the generic search facility, however there are a number of references to file based searches. File based searches to not make sense for this particular application because of the database storage system. Also, some of the required plugins contribute text support actions which also do not make sense for this application. By splitting the org.eclipse.search plugin you allow me to re-use the search framework without requiring me to bundle text & file searches as well. As the plugin stands now I am going to have to hack & slash to get the search framework to not show the text search functionality.
We discussed this here. The idea is definitly good and also not that difficult as the code is already quite separted. Unfortunatly we can't promise that for 3.1, no time budget for that so far. Will keep you updated.
I am willing to perform the operation if that would make it possible to have it done for 3.1. I propose the following solution: 1. Create an org.eclipse.search.base plugin which contains just the search functionality (no text search functionality). The org.eclipse.search plugin will require and export the org.eclipse.search.base plugin. This way we won't break anybody's plugins. 2. Move the non-text packages to their new home. 3. Fix the internationalization. I don't know of a smooth way of transisitioning the message property files. Do you? I could do some investigation into allowing multiple property files to exist, one master list for both plugins and two smaller lists with just the strings neccessary for the respective plugins. Later, after the translations of the smaller files are completed (cut/paste jobs) we could remove the master list. But like I said, I don't know if this is possible. Also would it be breaking API to remove the master list? Are there any other things I would need to do? Or worries you have? If you give me the go-ahead I will announce it to a mailing list to alert the other developers. Is there one in particular that I should address? Also since most of this work will be in fixing the translations, but no translation needs to be done I could copy/paste the translation files. Finally, since some of this could break API I will get Jeem involved at the appropriate time.
May I suggest another approach: the current Search plug-in has grown over years and it contains an old (deprecated) and a new search. We should take the opportunity and deprecate the whole plug-in and create two new ones: org.eclipse.search.ui (yes the current one does not even have UI in its name) org.eclipse.search.ui.text We could even dare to cleanup package and type names and offer a simple tool for easy switching to the new code base. Some other thing to consider when splitting the plug-in: there were requests that people want a core (i.e. headless) text search in a separate plug-in. I will answer further questions like i18 when splitting starts. One other thing: PBC needs to approve the new project(s) before they get created in CVS.
There were more discussion here with Dani, Erich, Dirk and me. I first thought that the current search plugin has no API regarding text/file search, but I forgot the Match class and all support classes for updating Matches on filebuffer changes ect... So we can not avoid an umbrealla plugin reexporting two new plugins. But we could do what Dani suggested: use this as a chance to separate the old search API from the new one. So with my current knowledge (surprises expected) a good split would be: 'org.eclipse.search.ui' would be a RCP compliant plugin, containing only API and implementation for the search dialog and search view UI. 'org.eclipse.search.text' including the file search infrastructure + UI and the Match API + supporing classes (all in package 'org.eclipse.search.ui.text'). 'org.eclipse.search' is reexporting 'search.ui' and 'search.text'. It would contain all deprecated old search code + old API. Extension points for the search dialog page and result view page would go to 'search.ui' but for compatibility reasons (extension point id is qualified with the defining plugin's id) we would have to duplicate them and let 'search.ui' look for both ('org.eclipse.search.ui.text.searchPages' and 'org.eclipse.search.ui.searchPages') Benefit of the split would be: - RCP plugins can use the search dialog and viw to centralize a place for all searches. - Plugins that converted to the new search API can directly depend on 'org.eclipse.search.ui' and 'org.eclipse.search.text' I feel that especially with the second benefit, arguments are good enough to convince the PMC to endorse the new plugins. Jed, it would be great if you could investigate in that direction, I also hope to find some time to give you support with that.
I see that we will have to duplicate the extension points. Would we have to duplicate the extensions? Are extension identifiers API? Usually the identifiers are exposed as string constants within classes in the plugin and people code to the constants rather than hard coding the extension identifiers. Also, since people want headless search perhaps we should split things out into the following plugins. org.eclipse.search.core org.eclipse.search.core.text org.eclipse.search.ui org.eclipse.search.ui.text And then re-export all four as org.eclipse.search and include the deprecated API. Then we can deprecate the entire org.eclipse.search plugin and get rid of it when 4.0 rolls around (or never, as the case may be). If I start this I don't expect to be done until M5 (don't have a whole lot of free time). Is that too late in the release cycle to make a large change like this?
The UI-Core split is too much. So far I haven't heard of a requirement for search core plugins. There's no real org.eclipse.search.core, it's all dialogs. org.eclipse.search.text.core would only contain the file search infrastructure which is simple enough so it can be copied if somebody badly needs it. M5 is fine. As I see it now we won't break anybody. If I find time I might also start with it.
Agree with Martin that dividing into Core and UI is too much. I just wanted to point it out. >If I find time I might also start with it. Just ensure you don't work both on it ;-)
I think the extension points may be problematic. Existing clients contribute to the 3 extension points currently declared o.e.search; for API compatibility, these would remain there. If you introduce copies of these extension points on o.e.search.ui, then someone needs to consolidate the contributions to both. The logical place for that code is in o.e.search.ui. Since o.e.search.ui cannot depend on o.e.search and needs to work even when o.e.search is not around, the code that does the consolidation must do a carefuly dance. The o.e.search.ui should be able to query platform to find out if o.e.search is present, and then use extension registry to get at contributions to o.e.search's extension points. Regarding extension identifiers: Java compilers must inline references to all constant fields with compile-time-computable values. So the class files for existing client code probably has the hard-coded strings regardless.
I was thinking the code would work the other way around. For example the org.eclipse.search plugin would harvest extensions from the org.eclipse.search.ui plugin. If the org.eclipse.search plugin didn't exist the org.eclipse.search.ui plugin would happily use its own. However, the point may be moot if we cannot change view identifiers. Which brings me back to the original idea. Just splitting the plugin. If we kept most of the code in the org.eclipse.search plugin and added an exported and soft dependency on a new plugin org.eclipse.search.text then RCP developers could just ship the org.eclipse.search plugin, whereas the SDK and other text based tooling could ship both. It's been a while since I talked about plugin dependencies, is "soft" the right term?
Jim, I don't think org.eclipse.search.ui needs to care of org.eclipse.search exists to read extensions contributed to its extension point. The code in 'org.eclipse.search.ui' would do a r= Platform.getExtensionRegistry(); exts1= r.getConfigurationElementsFor("org.eclipse.search", "searchPages"); exts2= r.getConfigurationElementsFor("org.eclipse.search.ui", "searchPages"); to get all search pages. Wouldn't that work? With Jed's proposal, org.eclipse.search would have to reexport org.eclipse.search.text but also have to mark it as an optional plugin. Is that possible?
I agree. The extension point should be doable. I'm not sure either whether reexporting an optional dependent plug-in is allowed. It would certainly be unusual. It would mean that a client plug-in that requires o.e.search gets access to org.eclipse.search.text's classes if it's around.
How did core solve these problems when they pulled the IDE out of the workbench? Could we solve this similarly?
Pulling the IDE-specific extension points out of o.e.ui into o.e.ui.ide was a breaking API change we made in 3.0. We put special code in core runtime to automatically map references to old extension point ids to preserve binary compatibility for existing deployed plug-ins. But I doubt we would do this again if we did not gain as much as we did from extracting RCP.
Please see if you can get rid of the dependency on the IDE plugin that org.eclipse.search has. Right now we're building an RCP application and would like to make use of the various extensions provided by org.eclipse.search. However, because of the IDE dependencies we essentially have to move all search related functionality into our RCP application or ship with a modified org.eclipse.search - not very extensible. For 3.1 we have no choice but it would be nice to see this split happen in future versions of eclipse. Please let me know if you need any feedback on this - I will be happy to provide it. Thanks, Ish
*** Bug 109579 has been marked as a duplicate of this bug. ***
*** Bug 122468 has been marked as a duplicate of this bug. ***
I too am working on an RCP application with search requirements very similar to what eclipse provides and would like to avoid re-inventing the wheel so to speak. The interdepencies that the current search imposes is a real issue for us. For now we are going to try to use Activities/Capabilities to 'hide' whatever ui contributions we don't want to see, but this is less than ideal. The last real contribution to this bug was sometime in late 2004, now that more than a year has passed is there any hope of this bug getting fixed, and if so what sort of time frame? Is there any chance of this making it into 3.2?
Unfortunatly we can't promise that we have time for this in 3.2. Note that this is a major change, we're not even sure if it is possible to do in a non-breaking way. Help is welcome, see the discussions in the bug about the way to go.
As RC1 is already out, I expect this split will not be performed before the 3.2 release cycle is complete. I am curious as to when this will receive attention? Is this a 3.3, 4.0? I would like to know because if this is not a near future fix (6 months to a year), I will need to roll my own. Does anyone have any estimations?
I wanna make use of the search plugin now in our non-resource base RCP application and the dependencies on IDE are very annoying. Has there been any work going on this issue for the last year? If not, we need to roll our own search facilities as IDE pulls just too much into preference pages, toolbars and views. The suggested split of the plugin here sounds fine to me. Anybody working on this?
To my knowledge nobody is working on this and it is not planed from our side. Help would be most welcome.
*** Bug 221507 has been marked as a duplicate of this bug. ***
This is coming pretty soon. A friend of mine has already created a patch that strips all IDE code from the search bundle and its still working. Some more internal tests and the patch will be submitted here. Stay tuned!
After creating a stripped-down version of the search plugin (w/o file and text search nor IDE dependency) for my project, I'm now working on an upstream-compatible version of my changes suitable for the current HEAD. Ideally, this should break as little as possible, but I think that breaking some eggs while making this omelet will be inevitable... My current goal is to split the bundle into org.eclipse.ui.search org.eclipse.ui.search.text org.eclipse.ui.search.file File search depending on IDE shouldn't be a problem, as I understand. Same for text search, if it should be required. However, that should leave me free to cut all dependencies from the main plugin except core, o.e.ui, o.e.ui.forms and o.e.jface. I'm not sure if I should do anything about the search/new search problem. If I understand correctly, there's an old search interface which has been deprecated for some time now. Maybe this refactoring, which will probably break some stuff anyway, would be a good opportunity to clean up these interfaces, too. Although 3.5 has already been frozen, I'm pretty confident that I'll have this ready for release before 3.6 ^^
> but I think that breaking some eggs while making this omelet will be > inevitable... Note that for the 3.x stream API and hence existing plug-ins cannot be broken. >org.eclipse.ui.search.text What would be in here? Headless text search? If so, this should be named org.eclipse.core.search (org.eclipse.core.search.text)
*** Bug 301247 has been marked as a duplicate of this bug. ***
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
