Community
Participate
Working Groups
Created attachment 176614 [details] Search console source code Hi, As disscussed with Boris Bokowski and Karsten Schmidt (in CC) at the end of April, we (SAP) would like to contribute a compoment called "Search Console". The search console is a highly extensible framework which allows easy and unified integration of searching and consuming artifacts within Eclipse environment. The extensisiblity is implemented via several extension points. The search console provides two Eclipse views - the very "Search Console" view and "Search Favorites" view grouped under the "Saerch Console" views category. The search console view is the component which performs the very search. Contributors may - define their own artifact types - specify their own destintaions to perform the search in - contribute a custom search parameters user interface - should conitrbute a designated interface implementation which performs the search The view also provides a section to display the search result. The "native" results user interface would show the search result as a tree. Contributors may - specify their own label/content/tooltip providers - install custom actions in the context menu or on a designated toobar The results UI implements properties view connectivity thus allowing contribution of custom property view tabs via the standard eclipse properties extension points. Drag from the results UI is also supported. Contributors are also able to embed their own search results user interface in the search console view in case the native one does not suite their needs. If they do so, they should however implement the complete integration with the Eclipse environment (context menues, properties, drag-and-drop, etc) on their own. Both search parameters and search results components are embedded in a single view. Thus the user is capable of seeing both query parameters and result at the same time. If the result does not satisfy the user, the search parameters can be edited and the search can be executed again. The search favorites view implements the concept of bookmarking "favorite" search results. The favorite items are persisted and remain bookmarked after Eclipse restart. In order to get their search result items in the favorites view contributors - could specify their own label/content/tooltip providers - could install custom actions in the context menu or on a designated toobar - should contribute implementations of designated interfaces which persist and load favorites items Drag-and-drop from the native search result UI to the search favorites view is natively supported by the framework I am aware that I should provide more technical details on the extension points and the architecture of the framework. I don't have such details in hand but will start woking on such documentation soon. The extension point schemas and the very source code contain pretty much javadoc but I think that that it is not sufficient for a contributor to understand what to do in order to plug into the console. The archived source code proposed is attached. In the "plugins" directory of the archive you may find the "productive" plugins and in "tests" you may find the automated tests plugins. The naming convention of the plugins follows the "org.eclipse.platform.discovery.*" pattern. Each plugin has its test counterpart. The automated tests provide more than 75% overall code coverage. Each test plugin has a "AllTestsSuite" class which is the suite for executing all the tests contained in the plugin. The "productive" plugins depend on Eclipse functionality only and do not deal with any cryptography. The test plugins depend also on JMock 1.x (http://jmock.org/) for unit tests and Abbot (http://abbot.sourceforge.net) for UI tests. JMock has been approved during JAX-WS DOM tools contribution (https://bugs.eclipse.org/bugs/show_bug.cgi?id=283846) and is already a part of the WTP/webservices project as "org.jmock". In order to avoid code duplications it should be probably moved to another place in order search console tests to reference it. As far as I know Abbot has not been discussed till now. Abbot eclipse plugins (abbotswt) can be downloaded from http://sourceforge.net/projects/abbot/files/abbot.swt/0.1.0.20080305_1254/abbot.swt-0.1.0.20080305_1254.zip/download There is a kind of an issue with the Abbot tests. In order the tests to run successfully it should be provided that the test workbench window is on top of all other windows. This is usually the case for newly opened windows but it is not 100% guaranteed. Implementation for MS Windows which can assert that is provided (check the commented code in org.eclipse.platform.discovery.testutils.utils.abbot.util.PDEUtil). Unfortunately this implementation uses specific Win32 APIs and is not portable to other platforms. That is why this coding is commented. It would be great if someone has an idea how to achieve this via platform independent code. The feature proposed is completely developed by SAP and SAP has given the agreement for contribution under the EPL licence. Here are the SAP employees who contributed to the code: - Hristo Sabev - Danail Branekov - Mladen Tomov - Martina Galabova - Iliyan Dimov - Dimitar Georgiev - Richard Birenheide - Joerg Dehmel Let me know in case you have further questions. Best regards, Danail
Created attachment 177361 [details] Search console source code There were some minor improvements implemented lately and therefore I am attaching a second version of the source code. Marking the first attachment as obsolete. - Danail
(In reply to comment #0) > The test plugins depend also on JMock 1.x (http://jmock.org/) for unit tests > and Abbot (http://abbot.sourceforge.net) for UI tests. How much of the test code is dependent on Abbot? Would it make more sense to go through the IP review process for that (potentially longer wait, risk of it not being approved, and more work for the Eclipse Foundation IP staff), or to rewrite the tests based on another framework such as SWTBot (more work on the SAP side)? If we wanted to speed things up, we could also split the contribution into two pieces, the functional code and the corresponding tests. Do you have a preference?
Boris, can you estimate how long would it take to get an eventual approval for abbot? This could bring some idea for answering your questions :) Regards, Danail
Even if we want to get the abbot-test stuff I'd suggest an extra CQ for it because so the test-code would not block the integration SCM and finally into the build.
Danail, when we discussed this in the call you mentioned in comment 0, we agreed that the implementation has to allow to show the current search results in the new Search Console so that it will be able to replace the current Search view and also provide value add for existing searches. From a quick glance at the attached patch it looks like this is not the case. Did I miss something?
> it will be able to replace the current Search > view and also provide value add for existing searches. From a quick glance at > the attached patch it looks like this is not the case. Did I miss something? No, Dani, you are not missing anything. The source code proposed provides just the framework on top of which search implementations should be integrated. This means that in order to get the existing search features into the console there should be a couple of integration plugins which contribute stuff to the search console extension points. This is however a matter of future work.
(In reply to comment #6) > > it will be able to replace the current Search > > view and also provide value add for existing searches. From a quick glance at > > the attached patch it looks like this is not the case. Did I miss something? > > No, Dani, you are not missing anything. The source code proposed provides just > the framework on top of which search implementations should be integrated. This > means that in order to get the existing search features into the console there > should be a couple of integration plugins which contribute stuff to the search > console extension points. This is however a matter of future work. I see. Note though that for an inclusion in 3.x or 4.x this needs to be present.
Hi Dani, Yep, we understand this. However we'd like to setup the project and resolve all IP stuff before this work as we would like to take advantage of other contributors during the task of bring existing eclipse search into the search console. Regards, Hristo (In reply to comment #7) > (In reply to comment #6) > > > it will be able to replace the current Search > > > view and also provide value add for existing searches. From a quick glance at > > > the attached patch it looks like this is not the case. Did I miss something? > > > > No, Dani, you are not missing anything. The source code proposed provides just > > the framework on top of which search implementations should be integrated. This > > means that in order to get the existing search features into the console there > > should be a couple of integration plugins which contribute stuff to the search > > console extension points. This is however a matter of future work. > I see. Note though that for an inclusion in 3.x or 4.x this needs to be > present.
(In reply to comment #8) Also sharing the code and getting feedback from you and other folks would be much easier this way. > Hi Dani, > > Yep, we understand this. However we'd like to setup the project and resolve all > IP stuff before this work as we would like to take advantage of other > contributors during the task of bring existing eclipse search into the search > console. > > Regards, > Hristo > > (In reply to comment #7) > > (In reply to comment #6) > > > > it will be able to replace the current Search > > > > view and also provide value add for existing searches. From a quick glance at > > > > the attached patch it looks like this is not the case. Did I miss something? > > > > > > No, Dani, you are not missing anything. The source code proposed provides just > > > the framework on top of which search implementations should be integrated. This > > > means that in order to get the existing search features into the console there > > > should be a couple of integration plugins which contribute stuff to the search > > > console extension points. This is however a matter of future work. > > I see. Note though that for an inclusion in 3.x or 4.x this needs to be > > present.
The legal review of this contribution is currently waiting on this question from the Eclipse Foundation legal team (from CQ 4455): > In light of Karsten Schmidt's involvement, can you > arrange for Karsten to provide a confirmation on the bugzilla bug that SAP > confirms their agreement to contribute the contents of this bug to Eclipse.
(In reply to comment #10) Sure, I'll talk with Karsten. The only thing that bothers me is how he should provide the needed confirmation. Is stating this inside this bugzilla enough? > The legal review of this contribution is currently waiting on this question > from the Eclipse Foundation legal team (from CQ 4455): > > > In light of Karsten Schmidt's involvement, can you > > arrange for Karsten to provide a confirmation on the bugzilla bug that SAP > > confirms their agreement to contribute the contents of this bug to Eclipse.
Yes, just a comment in this bugzilla is good. You have already done that in comment #0, but maybe since Karsten's name doesn't appear in that list of contributors they wanted clarification from him? If Karsten didn't contribute to the code and the list of contributors in comment #0 is accurate, then I don't think anything more is needed here.
(In reply to comment #12) Sorry somehow after your last post I got a bit confused whether we need Karsten's confirmation. I could see that he's on cc list for this bugzilla though. The list of contributors is accurate and Karsten didn't contribute to the code. Still it's no issue to get his approval. We just need to wait few more days > Yes, just a comment in this bugzilla is good. You have already done that in > comment #0, but maybe since Karsten's name doesn't appear in that list of > contributors they wanted clarification from him? If Karsten didn't contribute > to the code and the list of contributors in comment #0 is accurate, then I > don't think anything more is needed here.
SAP confirms the contributors' agreement to contribute the contents of this bug to Eclipse
The Eclipse Foundation legal review (CQ 4455) has the following questions about the code: 1. LocalContextSelectionTransfer.java is matching to an existing Eclipse file (same name) containing copyright to IBM starting in 2005. If the project has made a derivative work of this file, the copyright header should be reverted to the original with Contributor info being modified.... 2. AbstractMockObjectTestCase.java is matching to MockObjectTestCase.java from Jmock. Is AbstractMockObjectTestCase.java a derivative work of the Jmock file or ???
The story is different for the two files: LocalContextSelectionTransfer is not derivative of the same file inside eclipse. Actually I made a fast search in google and in my eclipse and I didn't find a file with the same name. There is a class called LocalSelectionTransfer though. The classes are somehow similar but I guess that this is so because they follow the guide-line and common sense for writing new drag & drop transfers. The AbstractMockObjectTestCase may indeed be considered derivative work of the MockObjectTestCase from JMock 1.1. It introduces support for generics as well as it solves a problem with mocking classes in signed jars. Otherwise the best part of the class is structurally the same. (In reply to comment #15) > The Eclipse Foundation legal review (CQ 4455) has the following questions about > the code: > > 1. LocalContextSelectionTransfer.java is matching to an existing Eclipse file > (same name) containing copyright to IBM starting in 2005. If the project has > made a derivative work of this file, the copyright header should be reverted to > the original with Contributor info being modified.... > > 2. AbstractMockObjectTestCase.java is matching to MockObjectTestCase.java from > Jmock. Is AbstractMockObjectTestCase.java a derivative work of the Jmock file > or ???
I think the legal team is referring to LocalSelectionTransfer in JFace. Here is the class comment from the JFace class: * A LocalSelectionTransfer may be used for drag and drop operations * within the same instance of Eclipse. * The selection is made available directly for use in the DropTargetListener. * dropAccept method. The DropTargetEvent passed to dropAccept does not contain * the drop data. The selection may be used for validation purposes so that the * drop can be aborted if appropriate. And here is the class comment from the Search Console class: * A LocalContextSelectionTransfer may be used for drag and drop operations * within the same instance of Eclipse when context info is needed. * The selection is made available directly for use in the DropTargetListener. * dropAccept method. The DropTargetEvent passed to dropAccept does not contain * the drop data. The selection may be used for validation purposes so that the * drop can be aborted if appropriate. It's unlikely this is just coincidence. There is even a comment in LocalContextSelectionTransfer where the author forgot to rename the class: // First attempt to create a UUID for the type name to make sure that // different Eclipse applications use different "types" of // <code>LocalSelectionTransfer</code> This isn't a big deal since both the original code and the contributed code are EPL - it's just a matter of updating the copyright header. I'll copy over the comments made by the foundation legal team about how to make it right.
Here is the comment from Eclipse legal: #1 - Reverting to the original copyright header will resolve the issue. If SAP contributed to the file, they can update the Contributor Section with that information. #2 - The contribution has leveraged code from JMock. Therefore, e4 will need to raise a CQ for Jmock. Good news though, CQ 3450 has been approved for Jmock version 1.2 (Subset). I've checked the code attached to it and the particular file was included. If that version of the file works in this case, a Piggyback CQ will do the trick. [I wish the Foundation legal folks could talk to you directly rather than someone copying/pasting between bugzilla/CQ. I have CC'd Eduard Bartsch and Karl Schmidt on the CQ in case that helps simplify communication]
That's a it strange, the source code in our source control system doesn't have this javadoc. Perhaps it has been added for the contribution, but it's really almost identical to that of eclipse. It's not issue for us to put the eclipse copyright header:) Anyway the code goes back to eclipse. A new attachment will be provided, probably this Monday 4th. Oct. 2010 JMock 1.2 works fine. Karl Schmidt? Maybe you meant Karsten? He has asked me to take over the CQ activities on behalf of him... (In reply to comment #18) > Here is the comment from Eclipse legal: > > #1 - Reverting to the original copyright header will resolve the issue. > If SAP contributed to the file, they can update the Contributor Section with > that information. > > #2 - The contribution has leveraged code from JMock. Therefore, e4 will need > to raise a CQ for Jmock. Good news though, CQ 3450 has been approved for Jmock > version 1.2 (Subset). I've checked the code attached to it and the particular > file was included. If that version of the file works in this case, a Piggyback > CQ will do the trick. > > [I wish the Foundation legal folks could talk to you directly rather than > someone copying/pasting between bugzilla/CQ. I have CC'd Eduard Bartsch and > Karl Schmidt on the CQ in case that helps simplify communication]
(In reply to comment #19) Yes sorry I meant Karsten! Unfortunately the CQ system is only accessible to current committers, which is a bit of a problem when working with new contributions from people who aren't yet committers. Anyway an existing committer such as Boris or myself can continue acting as the proxy between the two systems...
> Perhaps it has been added for the contribution Yes, Hristo, the copyright header is not part of our SAP sources. However, it is required when you contribute the code. I used a tool for setting it across all files automatically. I will provide a new version with the copyright header updated.
Created attachment 180106 [details] Developer guide Here is the document I promised some time ago in ODT and PDF format. It should provide some useful information about how the framework works and how to contribute to it.
Created attachment 180107 [details] Sample contribution And here is a sample contribution which will search for local cheat sheets. Not the smartest feature possible but demonstrates quite some of the framework features.
Created attachment 180108 [details] Search console source code Search console source code with updated copyright header of LocalContextSelectiontransfer
Is this related to bug 242235 ? Will this simplify searching files outside the workspace ? Are there any plans to also contribute this to the Eclipse 3.x Stream ?
Yes, this should simplify searching outside of the workspace through the use of configurable (and plugable) destinations, the workspace being one of them. As for the plans for e3, I doubt it. It's quite a big change and existing search is going to look quite ugly inside the search console. (In reply to comment #25) > Is this related to bug 242235 ? > Will this simplify searching files outside the workspace ? > Are there any plans to also contribute this to the Eclipse 3.x Stream ?
Is somebody going to submit this code into the SVN? How we go about ellecting committers to start working on the needed improvements? (In reply to comment #26) > Yes, this should simplify searching outside of the workspace through the use of > configurable (and plugable) destinations, the workspace being one of them. > As for the plans for e3, I doubt it. It's quite a big change and existing > search is going to look quite ugly inside the search console. > (In reply to comment #25) > > Is this related to bug 242235 ? > > Will this simplify searching files outside the workspace ? > > Are there any plans to also contribute this to the Eclipse 3.x Stream ?
Hi guys, CQ 4455 (http://dev.eclipse.org/ipzilla/show_bug.cgi?id=4455) has been set to "approved" state. How do we proceed? Is someone of the current committers willing to get the code into the incubator repository? Or you would prefer to start new committer elections? Regards, Danail
(In reply to comment #28) > Hi guys, > > CQ 4455 (http://dev.eclipse.org/ipzilla/show_bug.cgi?id=4455) has been set to > "approved" state. How do we proceed? Is someone of the current committers I've opened bug 330000 to get it into either CVS or GIT, depending on the preferences of your team. Please comment on that bug. Boris will start committer elections. PW
(In reply to comment #0) > Here are the SAP employees > who contributed to the code: > - Hristo Sabev > - Danail Branekov > - Mladen Tomov > - Martina Galabova > - Iliyan Dimov > - Dimitar Georgiev > - Richard Birenheide > - Joerg Dehmel Who would be the people working on this in the e4 project?
(In reply to comment #30) > (In reply to comment #0) > > Here are the SAP employees > > who contributed to the code: > > - Hristo Sabev > > - Danail Branekov > > - Mladen Tomov > > - Martina Galabova > > - Iliyan Dimov > > - Dimitar Georgiev > > - Richard Birenheide > > - Joerg Dehmel > > Who would be the people working on this in the e4 project? It would be good if I can also access the code. Boris, can you add me when the e4 election is done? Thanks.
This is the list of people: Martina Galabova Dimitar Georgiev Danail Branekov (In reply to comment #31) > (In reply to comment #30) > > (In reply to comment #0) > > > Here are the SAP employees > > > who contributed to the code: > > > - Hristo Sabev > > > - Danail Branekov > > > - Mladen Tomov > > > - Martina Galabova > > > - Iliyan Dimov > > > - Dimitar Georgiev > > > - Richard Birenheide > > > - Joerg Dehmel > > > > Who would be the people working on this in the e4 project? > It would be good if I can also access the code. Boris, can you add me when the > e4 election is done? Thanks.
FYI, I have logged CQ https://dev.eclipse.org/ipzilla/show_bug.cgi?id=4662 for approving Abbot test framework
Thea abbot CQ has been approved for some time now. The very test code is not yet part of the build, but the issue is being tracked separately: https://bugs.eclipse.org/bugs/show_bug.cgi?id=331018 The epic on integrating existing search providers is also tracked separately, https://bugs.eclipse.org/bugs/show_bug.cgi?id=331581 , as will be future epics such as - search result paging/history - support for multiple instances of search console Therefore I don't see a reason to keep this bug open any longer. If anyone does not feel the same way, they should feel free to reopen this. Cheers, Dimitar
