Semantic-aware component provisioning: "pencils off" status report

I want to recap my summer of code so far, before the final evaluation starts. Here's what I accomplished so far. It was a lot of work, and a huge fun as well, hope to catch your interest and get some feedback on future developments! :)

GUI CONTRIBUTIONS

• new component submission view (drag and drop support from the repository explorer to add dependencies easily :) )


• repository explorer view


• preference page (set repository URL)

IMPLEMENTED FEATURES

• submit a new component


• usual search features (name, version, tags)


• search components providing a set of tasks


• search components providing all the tasks of the selected ones


• "smart" search of components functionally equivalent to the selected one (reasoning here)


• search components depending on the selected one


• assert functional equivalence between components

HANDS-ON

Let's take a test drive. I submit a new component, in this case (just as an example) the "last-gsoc-demo" one. I fill in some data, and press submit. I can just drag-and-drop dependencies from the repository explorer to the dependencies viewer.



I previously submitted some sample components. Now since all jdbc drivers implement the same specification, to some extent it is correct to consider them "functionally equivalent", and I push this statement in the knowledge base.



For sake of brevity I ask you to trust me without further shots, what I did is just assert all jdbc drivers in the repository (besides the "dummy-jdbc" one) "functionally equivalent" to the postgresql one, and then assert the "dummy- jdbc" only equivalent to "mysql-jdbc". I can ask now the repository to give me components "functionally equivalent" to the selected one ("dummy-jdbc"), just clicking on the context menu item:


Here's what I obtain:



You might notice that the selected item is still there, which makes sense since everything is of course functionally equivalent to itself. ;) Furthermore, it is worthwhile to note I only said the "dummy-jdbc" was equivalent to "mysql-jdbc", full stop! The rest is just the result of the reasoning process.

Now, I can also describe a component in terms of the "tasks" it carries out. Let's suppose - just as an example - I have two components, one for "dom-parsing" and the other for "sax-parsing".



Suppose now I was not on earth in the last years and I want to know if there exists a single component doing the two things.



I can select both of them, click on the shown item and I'll get xerces-j actually does both things. I might decide to use it if it fits my needs, since a single dependency is better than two, in most cases.

I also could want to know if other components rely on mine, or for instance how many components actually use one, which usually means it has great reputation. Remember the "last-gsoc-demo" component? I put "mysql-jdbc" as a dependency there. I just right click on the component, and find the components depending on the selected one. :)



CLIENT-SERVER ARCHITECTURAL VIEW (after latest modifications)



KNOWN BUGS

• troubles with SPARQL queries involving literals: searching against id and tasks is ok, versions and tags are not (yet the http://repo.url/tag/{tag} resource works fine... i had no time to investigate further befor pencils were off)


• dangling dependencies (i.e. after a delete operation) are not handled yet.

COMING SOON (random order)

• rest (not in the soa-ish meaning)


• enable license and license-style search criteria on the plugin


• associate a new perspective with the provided views


• improve repository explorer (i don't like that tree very much)


• bundled repository exploiting the eclipse embedded jetty server


• import existing metadata from maven POM or OSGi manifest (URL drag and drop from web browser?)


• address repository data access layer performance issues


• setup an update site somewhere on the globe

CHEERS
That's all for now, I really enjoyed the work, and I am confident this both- side fruitful collaboration will go on. A lot of things remain to be done on this project, and I won't let it down after Google Summer of Code stops.

I want to thank Philippe Ombredanne for mentoring me, and all the guys @ #eclipse-soc for supporting me and other students day after day. It was an invaluable experience to work with you guys.

See you online,

cheers,

Savino Sguera.

Status: Improving Eclipse Search

My greatest fear ( getting sick ) for SoC has become true this summer and it forced me to sleep / lie down doing nothing for about a week. However, I have another small addition for Find/Replace facilities.

This enhancement is Emacs style "Case Sensitive Replace". Here's the bug:

Retain Caps When Replacing - https://bugs.eclipse.org/bugs/show_bug.cgi?id=28949

It's waiting for code review.

About "Highlight All": I've received feedback from Daniel and I believe I'll complete the patch with a final blow. I should say that as a user, I find these two enhancements quite handy.

About lightweight Find/Replace: I've seen that the area below the editor is not sufficient for displaying the bar completely. It looks good under the editor when resized but the area below the editor is small in width in a vanilla Eclipse install.

To overcome this, I think that it's best to form the bar as a Trim contribution (top/bottom). This way, we'll have a pretty good amount of width and the users that want to use the bar in some other place will also be satisfied.

However we need to resolve bugs like https://bugs.eclipse.org/bugs/show_bug.cgi?id=195776 first. We need to have a bottom trim that can resize itself when contributions do not fit. I discussed the issue with Eric Moffatt and he said that we'll have TrimLayout improvements in M3 and M4. In this case, I'm thinking of creating this "lightweight Find/Replace" as a trim contribution and use the coolbar (which wraps and resizes correctly) for now. When we have Eric's improvements, we can carry it to the bottom trim as in Firefox.

Feel free to comment (especially on this last paragraph). :)

Have a nice weekend,

Parts, drugs and Fullscreen

Fullscreen is often an eyecatcher - isn't it? ;)
But I didn't wrote that to annoy you but to tell that the SWT team (especially Kevin Barnes) just committed fullscreen support for SWT shells. I'm really happy that my patches - which were part of my Google Summer of Code project - found their new home in the Eclipse CVS.
If you're one of the lucky ones working with SWT HEAD or any of the upcoming N-builds you can do something like this in order to turn your shells into real fullscreen windows:

Display display = new Display();
final Shell shell = new Shell(display, SWT.SHELL_TRIM);

Button bFullscreen = new Button(shell, SWT.PUSH);
bFullscreen.setText("switch fullscreen");
bFullscreen.addSelectionListener(new SelectionAdapter() {
public void widgetSelected(SelectionEvent e) {
shell.setFullScreen(!shell.getFullScreen());
}
}


When running this little application and clicking the button, you'll get a fullscreen shell which covers the the whole space of your active screen.
As this a really nice-to-have feature of Eclipse, I'm currently working on a new command/handler/keybinding for the workbench to allow the user to switch the IDE into a fullscreen application.

Besides this there is another major task planned for my SoC project - Detached Windows. Sometimes hated, sometimes loved. I've to say that I really love them...but only my patched version which can hold serveral ViewStacks (folders of views) in one window. It could look like the on on the right.


As I really follow the term "eat your own dogfood", I'm working on my SoC project with two screens:
Screen 1: Eclipse IDE in fullscreen mode which covers everything else on that screen
Screen 2: a detached Window which allows me to arrange my views and folder just like the workbench window itself
Interested? Here is a picture of my current desktop (caution: ~400kb, 3360px*1050px):

Groovy Plug-ins: Bundle Activation and Extension Point Processing

I faced an issue with the bundle activation last week. Namely, a bundle activator will not be started if the given bundle doesn't contain any classes. I.e. a bundle activator is provided by my plug-in and the contributor should use this class to enable scripting for the activation routines.

I reported this issue to Eclipse Equinox newsgroup, and the feedback was quite positive in sense of the solutions. Tom Watson purposed some options:

• Have ScriptExtensionProxy activate the contributing bundle using a transient flag when it creates a proxy (i.e. call Bundle.start(Bundle.START_TRANSIENT)). This would take extra work for ScriptExtensionProxy because it should probably read the Eclipse-LazyStart and/or the new Bundle-ActivationPolicy from OSGi R4.1 specification to verify the bundle is actually lazy activated.


• Make ScriptExtensionProxy abstract and force contributing groovy bundles to extend it with a real class which exists in the contributing bundle. Then when the extension is constructed it will automatically activate the bundle if it has a lazy activation policy.

The 1st option worked, but it smells like a hack. I think that the contributor should never call the Bundle#start() on its own... FWIW, this method could be available only to the framework and not to the user.
I've sticked to the 2nd option, but instead of making the ScriptExtensionProxy abstract I will leave it as it is, so that user may just declare it in plugin.xml if there's no need for activation.
ScriptBundleActivator is just a facade for calling the activation script, which I presume to be called activator.groovy for now. The start() method call just delegates the work to the start() method of the expando object in the script.

The activator would be useful if the contributing plug-in will have the need for extension point processing, as the INVITATION RULE says: whenever possible, let others contribute to your contributions.

Here's the draft Groovy code for extension point processing in the activator:

import org.eclipse.core.runtime.Platform

def expando = new groovy.util.Expando()

expando.start = { bundleContext ->
 def registry = Platform.getPluginRegistry()
 def extensionPoint =  
 registry.getExtensionPoint(
   "org.eclipse.soc.scripting.contributor.listeners")
   
 def extensions = extensionPoint.getExtensions() 
 extensions.each( { extension ->  
   extension.getConfigurationElements().each({
     element -> 
     def object = element.createExecutableExtension("class")
     //do something with the object
   }) 
 } )   
}
expando   // this is the script returning object

While shaping the code above I realized what is the real power of such scripting: NO CASTING! Truly, I didn't think about it before.
Now I have the following:

1. A proxy for declaring the extensions: read here and here


2. A bundle activator facade.

This is the basic functionality which may be used for groovy plug-in creation (with some limitations). Currently I'm preparing a demo which could demonstrate how these base classes could be used.
Next, I would like to provide some usability enhancements to the core plug-in: it would be cool to modify the script even if it is already packed and deployed.
P.S. I have also blogged about the progress in my own blog.

Status, IDE Generator (Miguel Garcia)

I've been refactoring, adding functionality, yet I had the uneasy feeling that something was missing ...

Big revamp of Chapter 1 ("Frameworks for text editors: JFace Text and Gymnast Runtime") of the project report. With that, a user of the IDE generator is also in a position to understand (and further customize) the generated IDE. Features are classified, code snippets and references to further literature given.

----------------------------------------------------------------------

The features per category are:

a) The Gymnast Runtime extension to the JFace Text framework

• background parsing and notification of changes to the CST of the document
• context outline (with nodes implementing navigation back to the text region, and property source)
• custom problem markers
• parse-tree view

b) Customizations requiring CST or AST

• hovers over text fragments
• hovers over annotations (annotations on the vertical ruler)
• hyperlinks
• mark occurrences
• select in outline
• show in
• context menu on the editor surface, for example Go to Declaration
• views, for example EMF Type Hierarchy
• content formatting
• content assist

c) Customizations directly working on the document text

• document partitioning
• show range indicator
• bracket matching (brace, parenthesis, etc.)
• AutoEdits (for example, SmartBrace: after typing { in the JDT editor, an indented newline and a closing } are added below it). Another example is AutoIndent.
• Double-click strategy (in JDT, double-clicking an opening brace selects all the text up to the matching closing brace)
• Automatic Indentation

d) Document-independent customizations

• templates, including associated Preferences page
• actions on the toolbar and menu bar, in particular retargetable actions (i.e., those actions whose UI activators are shared between different editors, such as e.g. Content Assist)
• new file wizard, so that the document does not start empty but in syntactically valid state (thus avoiding spurious parse errors the moment background parsing kicks in)
• Preferences
  

----------------------------------------------------------------------

It's incredible the amount of detail hiding in each feature ... an Eclipse-based text editor can really be a machine with lots of moving parts ...

http://www.sts.tu-harburg.de/~mi.garcia/SoC2007/draftreport.pdf

Status: Improving Eclipse Search

Last week, I decided to implement "Highlight All" feature mentioned in Bug 29692, since it's a common enhancement request. I believe I've produced a patch that solves it. However I'm planning to implement "soft matches", that is if the user requests it, highlighting case-insensitive matches with a different color, case-sensitive whole word matches with a stronger color etc. like Ctrl+H Search does.


About the "lightweight find" ( Bug 99294 ), you should read Comment #24 about my current thoughts. The only problem with having "Find" and "Replace" fields on the bar simultaneously is visibility of all labels,buttons,fields on the bar at the same time on a vanilla install. Iconizing "Find", "Replace", "Replace/Find", "Replace All" buttons would save some space (these button labels can be written as tooltips). About "Options" group presentation problem, I thought of a bar-switch behaviour or a second bar appearing on the Find/Replace bar.

Another solution would be adding a second bar to appear for Replace and Options (shared use). The scenario would be like this:

1. Press Ctrl+F. You'll see a bar under the editor.
Only the Find bar:

[x] Find: [_____] [Next] [Previous] [Options...] [Replace...]

2. Press Ctrl+F again. Another bar will appear under the Find bar. This should be Replace bar. Find bar will "reform" itself.

[x] Find: [_____] [Options...]

[x] Replace with: [_____] [Next] [Previous] [Replace] [Replace All]

3. Pressing button will switch the second bar (Replace bar) with an "Options" bar.

It's still very open to discussion so I'm planning to implement it after we settle on an idea.

I hope to tackle other usability issues next week together with lightweight Find/Replace design.

That's all. Thank you for your feedback.

Status: Multi monitors against the rest of the world

Just to recap in the case you forgot about my SoC project: I'm hard at work improving the user experience on multi-monitor systems in Eclipse.

After struggling with building SWT on Windows Vista again - which worked fine some days ago - I attached all my fullscreen related stuff to the appreciated bug report in the hope that some of the SWT guys are willing to review the patches and getting them into CVS in the next days/weeks.
When the fullscreen support is in place, I can care more about the Workbench implementation of handling fullscreen stuff. There is already a working solution available but I think we can improve the one ore other little feature to make our users happy :-) I'll attach the code to the bug report immediately after the SWT guys committed the fullscreen support. Then everyone can participate to discuss more feature wishes. If you already have some nice ideas, let me know - best place would be a comment on the bug report.

After talking to Eric Moffat - the guy behind the black magic called presentation - we came up with a possibly good solution regarding improved detached windows (sashes, min/max behavior, etc) by replacing the current Detached Window implementation with a lightweight Workbench Window. Let us see how far we can come with this approach. I'll report about my progress in this area after working some days on this to see if it's that right way to go.

Status: Semantic-aware component provisioning

Recap: My project is about semantic-aware software component provisioning. Student: Savino Sguera - Mentor: Philippe Ombredanne.

• previous status report
  
• all about my GSoC project @ Eclipse (new window, personal blog)
  

Most significant updates for this week:

• Model refactoring
  
• Ontology design improvement
  
• Jastor classes update
  
• Implemented marshalling subsystem (XStream)
  
• Added persistency to Jena model (Apache Derby embedded DB)
  
• Tested full stack data flow:
  Restlet's DomRepresentation <-> Document <-> XML <-> Javabean <-> Jastor class <-> Jena statements <-> RDBMS
  
• Discussed dependencies licensing issues (no problems ahead)
  
• Started client's architectural design (and assessed code reuse scenarios)
  
• Added javadoc
  
• Committed new code to eclipse-incub

Very next steps:

• Discuss some modeling issues with Philippe
  
• Implement REST layer
  
• Get a live demo of the repository up and running
  
• Start client design
  
• Add a "dependencies" page to project's wiki

That's all for now.

Status: Improving Eclipse Search

There is significant progress in the project since last week. I reflected my initial ideas and conceptual work in Bug 195455 . The support for lightweight Find/Replace enhancement was great. Thank you for all the great ideas and responses. Discussion about this feature is continuing in Bug 99294 now.

Currently, I'm implementing (3a) from Kevin McGuire's comment which is:

3) Have it take up space in the layout somewhere,
3a) current option is within the text editor itself ala Firefox

As of today, remaining work is showing Options group and Scope group in the Find/Replace dialog in a good style, adding shortcuts, making sure of good performance.

I've converted Direction group in the dialog having "Forward" and "Backward" radio buttons in it, to a compact button that switches the search direction. This saves a significant amount of space on the Find/Replace bar and will be far more functional than having 2 radio buttons for this task IMHO.



An issue that may arise when I'm implementing (3a) approach is supporting search in ConsoleView etc. (anything other than the editor) in a good way. I think of carrying the same functionality ( offering Find/Replace in a bar ) in Toolbar of the ConsoleView. I expect to face a few issues about searching outside the editor.

This is it for now.
You can keep track of my progress in lightweight Find/Replace from https://bugs.eclipse.org/bugs/show_bug.cgi?id=99294 .

Thank you for all the ideas,interest and support.

Semantic-aware component provisioning: status report

Recap: My project is about semantic-aware software component provisioning. In my previous status report I dealt with the SWPO ontology design and a first architectural sketch of the repository, other than taking some significant decisions REST URI and resources to be exposed by the repository REST interface.

• Project wiki
• Previous update

I am glad to report about some significant progress in my project this week.

- Slightly refined the SWPO ontology (will upload fresh snapshot on the wiki asap).

- Got a good grasp on (and generated typesafe OWL2Java code mappings through) the IBM Jastor framework <http://jastor.sourceforge.net/>, part of the IBM Semantic Layered Research Platform <http://ibm-slrp.sourceforge.net/>. Generated code readability is awful, and I had to overcome some defects in handling inheritance and RDFList's, but at least it relieved the burden of writing the data access layer and Jena interaction from scratch. I will get the JUnit bar stuck on green in the very next days.

- Refined the repository architecture: three-tier, handling requests and resources' representations in a "pipes and filters" fashion. Assessed the chance of providing both a parsing and a marshalling subsystem in the application layer (will update architectural views on the project wiki asap). What I wanted to achieve was (and still is) to decouple the application layer both from the RESTlet framework and the specific implementation of the Data Access Layer, as much as possible.

- Created a module and committed code to eclipse-incub (I am actually updating the module quite frequently).

After a quite late start, finally things are smooth and running fine.

Cheers,
Savino Sguera

Status: scripting plug-ins

Official name: Add the ability to write plugins using jruby or groovy

First of all a slight change in the priorities. The top priority now is to enable the support of the bundles that are implemented using scripting language, i.e. Groovy and/or JRuby.

Others nice to have features will be:
1) Enable custom processing for plugin.xml, to be able test the new plug-ins without starting the 2nd eclipse instance.
2) The console, for providing the interactive (re)loading of the plug-in.

I have described to issues in more details in my blog entry.

Status: Improving Eclipse Search

Official name: Eclipse search plugin: providing a better, faster, more relevant Eclipse search

July 5th

Since my last blog entry about the project, there've been changes in the main goals of the project after discussion with my mentor Francois Granade and Daniel Megert.

Here are the current goals of this project:

General Goal:

• Unifying "Search" facilities so that there won't be 3 different search (and replace) functionalities in Eclipse

Specific Goals:

• Unifying Ctrl+F (Find/Replace dialog) and Ctrl+J (Incremental Search) by mostly behaving like Ctrl+J. Providing better UI utilization by not showing modal dialogs if the user doesn't request wider options. Summary of the idea: Firefox-style "Find" with enhancements. = a lightweight Find/Replace. Our main goal here is providing all functionality available in Ctrl+F with this lightweight Find/Replace. Here's the related Bugzilla entry: https://bugs.eclipse.org/bugs/show_bug.cgi?id=195455
  

• Providing "bridges" between Ctrl+F and Ctrl+H. This means carrying query information and search parameters back and forth between them when it's possible. --- To explain it better, it doesn't mean "sharing" input/settings, it is enabling the user to transfer "Find/Replace" input/settings to "Search" easily and extend his/her current search scope & query.
  

• Investigate better presentation of the search results in Ctrl+H ( adding an alternative view like Problems view - results in a table - might be a good idea to show result lines and numbers, paths etc. )

Current Progress

I'm working on a lightweight Find/Replace ( first Specific Goal above ) right now. I've converted IncrementalFind's Label widget on the status bar to a Text widget and using IFocusService I've managed to give cut/copy/paste input to this Text widget when focused.



For this lightweight Find/Replace, I've tried to create a prototype figure and attached it the Bugzilla entry https://bugs.eclipse.org/bugs/show_bug.cgi?id=195455. What I have in mind was basically a "Find" field appearing on the statusbar first Ctrl+F and when the user presses Ctrl+F again, "advanced feature" set appears as a menu above the status bar showing necessary checkboxes,parameters etc. but this prototype figure and behaviour is open to change.



After adjusting the behaviour of the code a bit , I'm going to work on the floating menu that will show up when the user requests "advanced Find/Replace features" next week.

I've created a feature and an update site for the project but even though the feature exports fine, when the feature is installed on a new Eclipse installation, Eclipse doesn't start. I've also tried to create a Plugin Fragment project first (since I've made all my modifications to org.eclipse.ui.workbench.texteditor), and then create a Feature & Update Site for it. This time, everything worked fine except that my changes to org.eclipse.ui.workbench.texteditor didn't show up in the new Eclipse installation.

I've committed my work as a patch to "soc-search" module in "eclipse-incub". It's very primitive right now but you can checkout anytime and see what I'm doing. First take a look at readme.txt to see how to build the project.

Host: eclipse-incub.cvs.sourceforge.net
Repository path: /cvsroot/eclipse-incub
Module name: soc-search

Feel free to comment here or on Bugzilla. Thank you for your time and feedback.

Plug-in Dependency Visualization

A lot has happened in my Summer of Code project over the past few weeks. To recap, my project has two main objectives; 1) to bring plug-in (bundle) dependency visualization to the PDE and 2) to solidify Zest, an information visualization toolkit for Eclipse.

Zest came out of some work I was doing for Mylyn, but we are now in the process of moving it to GEF / Draw2D. However, until this happens, we are still in the Mylyn repository and went through the move with them. After a bit of work, we are up and running again.

Zest has also been refactored to offer two separate APIs for Directed Graph Rendering. One API resembles SWT and the other one, JFace. In fact, I have created a number of snippets to show how these APIs can be used to create a view with a directed graph. During the refactoring I also removed all dependencies on the Runtime (we are now runtime free). This means that you can use Zest in your standalone SWT applications. Of course I still use the PDE tooling, so the JARs can also be used as an OSGi Bundle.


Finally, I have added container support to Zest. I plan on using this to group bundles in the dependency view. This should help with the scalability problems you get when you try and render a large graph. Nodes can now be added to containers and the containers can be expanded / collapsed. I am pretty sure I completed this without breaking any existing API, but if you use Zest and I broke something, please let me know. This feature was fun to implement, however, there are still some open issues. In particular, how to deal with connections that go from nodes in one container to nodes in another, and nested containers.

Semantic-aware software component provisioning: status report

Recap: This project aims to ease component provisioning by the use of Semantic Web technologies, providing a model - an OWL ontology - of the software component domain, supporting inference and reasoning about components' metadata and allowing developers to import metadata from a number of existing provisioning systems.

• project's wiki
• previous status report
  

During last week I had a couple of interesting chats with my mentor, Philippe Ombredanne, and with Pascal Rapicault as well, discussing some issues about the repository design and positioning in relation to existing component provisioning systems.

I'll briefly report what emerged from our conversations:

• model and metadata should be general, higher-level respect to the particular provisioning system. Each of existing systems focus on a particular aspect of component modeling, yet the metadata share much the same semantics so, as already hypotized in the previous status report, what we should aim to is providing a general metadata set, to map in turn the particular system metadata set. Some license-related issues about existing ontologies to reuse are being addressed during these days.
  

• an interesting idea (borrowed from the Equinox provisioning effort, thanks Pascal) which relates much to the previous point is to enable the repository to plug-in modules to integrate other provisioning systems' metadata repository, relieving the burden of writing over and over the same set of metadata. I'd start with OSGi and Maven repo modules.
  

• very interesting stuff @ easyeclipse about license-related properties of a sw component could be reused and/or wrapped (thanks Philippe ;) ).
  

• on the technology side we will rely upon a set of REST APIs, a servlet container and a SPARQL query engine (Joseki, very probably) to retrieve rdf metadata and carry out the inference process. This should be quite scalable, and simple enough to get the repo up and running as soon as possible. I am thinking about the RESTlet framework (just checked licensing issues, it looks ok), but if somebody has got better suggestions, please let me hear about.
  

I started designing the repository and refining the use case model, planning to have CRUD features available in the very next weeks. Architectural views coming soon to a blog near you.

That's all folks, eager to get some feedback,
cheers,
Savino Sguera

I've integrated a "grammar to Ecore-model" converter plugin to Gymnast. Interestingly, there's more than source code :) a chapter describing it along with some further pointers can be found in the (draft) progress report of my Google SoC project.

Have a nice weekend,

Miguel Garcia
http://www.sts.tu-harburg.de/~mi.garcia/

Status: Improving Eclipse Search

Official name: Eclipse search plugin: providing a better, faster, more relevant Eclipse search

May 15th

Training

I'm currently implementing an Eclipse plugin (about AJAX development – currently dealing mostly with manipulating/listening DOM document and nodes in embedded SWT.Mozilla browser – trying to implement a WYSIWYG HTML document designer) as a project at school so I had (and continue having) experience with Eclipse plugin development process with our project team at school. I've read a number of chapters from the book “Eclipse: Building Commercial-Quality Plug-ins” and I'm still reading.

After our initial discussions with Francois, this was a list of ideas about usability from Francois to familiarize myself with source code related with search features of Eclipse.

A few ideas for search usability
1) improve Ctrl-J search:
- Ctrl-J : have Ctrl-V paste the current ring in it
- Ctrl-J : if there's a selection, have a second Ctrl-J take this selection as search string
- Ctrl-J followed by Ctl-R would switch to regex search
- Ctrl-J to global search: transform a Ctrl-J to to a global search actually, drive all searches from the keyboard incremental search would be good: there should be a set of keyboard shortcuts on Ctrl-J to set up a complete search, and then execute it globally.
2) Display search results. the view that displays the search results is very poor currently. Probably a tree view is not perfect. It should show the matches, for example. It should have more shortcuts...
3) improve the search dialog. More TBD
4) real search/replace:
- search and replace in multiple files (all files/subset of files)
- selective (based on language elements...)

I had time to checkout and browse source codes in Eclipse CVS, find out which component does what and how it does that. However, I didn't have time to grasp the whole picture.

Problems/ Possible Enhancements to Address

Here is a list of issues from my little research in Eclipse Bugzilla about possible enhancements/problems to address:

1. find/replace search should have a tick-box for "ignore comments" (enhancement request)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=161398

2. Show as package tree
https://bugs.eclipse.org/bugs/show_bug.cgi?id=160481 (enhancement request)

3. Store Previous Searches for Startup (enhancement request)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=169252

4. Search dialog "Java Search" Scope should include Hierarchy (WONTFIX bug)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=110252

5. New text search shown line not a great help (LATER)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=127672
(This bug is waiting for applying styles on a tree item.)

6. Result in Table (LATER)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=129185

These two are related:
7. Search shows duplicate results in nested projects (LATER)
https://bugs.eclipse.org/bugs/show_bug.cgi?id=144959

8. Resource exclusion filters
https://bugs.eclipse.org/bugs/show_bug.cgi?id=84988
(read together with: https://bugs.eclipse.org/bugs/show_bug.cgi?id=144959 - about duplicate results for nested folder structures)

9. Search Enhancements
https://bugs.eclipse.org/bugs/show_bug.cgi?id=108223

10. Search in files: see matched lines
https://bugs.eclipse.org/bugs/show_bug.cgi?id=72575

Francois investigated the list and commented on it and it seems to me that I can make use of / address many issues in this list, either directly or indirectly.

Thoughts about the Main Part ( Lucene, OpenGrok etc. )

I tried to keep myself focused on research at the beginning so I read about both Lucene and OpenGrok. I understood how OpenGrok achieved to be a great tool for source code browsing and cross-referencing. Since it makes use of Lucene, either way (if I use OpenGrok or not) Lucene is a building block of this project. I've read a few articles and browsed a few presentations about Lucene and I'm still trying to learn more about it.

I've been consistently asking questions to myself about index sizes and frequent updates to the index. As a basic solution, I thought of keeping a partitioned index ( e.g. A project having an index that is distributed to multiple Lucene indexes and these index files being accessed/changed when it's necessary. Shortly, we may call this partitioning the index file. ).

This absolutely has a tradeoff because of the cost of not using one index for the whole project. But, when a good number of partitions is selected, I think that the tradeoff will seem small. (I thought of computing the ideal number in the future, like the computation of ideal bucket size in file processing literature.)

I thought of this “partitioning” method because an Eclipse user can get very aggressive when we tell him that we can “linearize” the time to search his files but in order to do this, he has to keep like ~ 50 MB for the index in RAM. ( I've tried indexing different things and I think that this value is a good estimate for large projects. And by the way, a possible question is why do I have to keep things in RAM and do not write things to disc. One answer: dynamic nature of source codes and frequent updates. )

Partitioning approach gives us one advantage: we only have to index a part of the project when you are working on a set of files. Since the number of active editors is considerably less than the actual project size, it is an idea that can work. And since we can keep a relatively small index in RAM, indexes containing your active file set can be updated fast.

However, I still see other tradeoffs in this approach and it is just a start. By the way, I'm trying not to focus on algorithm-wise enhancements for now and I don't plan to implement this idea in my prototypes during the early days of coding. I plan to start coding by addressing usability enhancements first.

I think early search plugin prototypes will makes use of RAM – HDD data transition features of Lucene and just write the index to a file on the disc after a certain threshold.

Todo List for Rest of the Interim Period

Well, I didn't have time to update the Wiki page of my project but I'll do it in 1-2 days.

Second thing that I feel I have to do before interim period ends is implementing little usability ideas from the list of Francois.

That's all for now.

If you have related ideas please feel free to send an e-mail. I'll be really glad to hear ideas about usability issues or Lucene / OpenGrok etc.

Status,Integate and Connect your Clients

Hi, all:
My project "Integate and Connect your Clients" is focused on building a platform to support mail client, Calendar and TaskList ,mentored by Wayne Beaton.

And I have done the following things:

1. Read related docs my mentors gave.

2. Looked into "Mail content","Mail attachment" and such problems.

3. Study sample codes,discuss with my mentor with the model design and function design.

Next i will try to add some new trial code to sample code.

Feel free to comment :)

Status, NetBeans in Eclipse

Hi all,

My Project goals are to provide a minimal NetBeans environment within Eclipse as Eclipse plugins and support running NetBeans plugins like Matisse. My mentor is Philippe Ombredanne. During the last 3-4 weeks I didn’t have much time for GSOC07 but I have done some work:

• I have contacted my mentor and we discussed the project goals. As first step I will implement a simple Netbeans’ plugin(an simple Editor) and try to find what is needed to run this plugin within Eclipse.
• I updated the wiki page of my Project.
• I started to read the documentation of NetBeans.
• I started to code the simple NetBeans’ plugin.

I will have much time for GSoC07 after 26st of May.

Criticism, suggestions and questions are welcome ;).

What's about this multi-monitor stuff?

Maybe you heard about this project yet - maybe not. The official name of my (Benjamin Muskalla) this years Google Summer of Code project: Improve the multi-monitor support in Eclipse. I have to say that the name maybe a bit delusive because all of the features are also available for single-user desktops. For example what I've implemented so far: Fullscreen mode for RCP applications. This is all about the native support of SWT to provide an option to set a shell into fullscreen mode (native or emulated) and use this to rearrange the layout of the product itself. As you can see if you try out the patches in the CVS repository, you can switch your Eclipse IDE to a fullscreen mode where Eclipse has the whole available space on your monitor, hides it's own toolbar/menubar and statusbar to give you as much space as possible to write code.
As I've only limited platform possibilities, there are only patches for Windows, Windows Vista and Linux GTK available yet - hopefully I can provide some more in the future. Additionally I put together a workbench handler to easily switch to the fullscreen mode (see screenshot). It would be really great to get some feedback from the community to improve the current work. One item I had a hot discussion with my mentor (Kim Horne) if we should provide an option to let the user configure their own fullscreen settings in the Workbench preferences. This way, the user could choose what to show in fullscreen mode: Toolbar on/off, Menubar on/off, etc...

Hope to post some exiting news in the next weeks about other interesting parts of the project like "Detached Views 2.0"!

So long I wish you a nice weekend :)

status, Semantic-aware software component provisioning

As of April, 11th, I've been mainly assessing code reuse scenarios, both for the ontology modeling and the repository design tasks; I've been working on the domain model, analyzing Maven repository's tag cloud, and getting a grasp on the OSGi specification as well.

A good axiomatization of the software component domain is given here @ cos.ontoware.com, and I think augmenting such ontologies would be nice for the project. They provide a quite granular description of a software component and library, which will support future development of the project, pushing formal description of software components down to interface- and method-level. I believe some sort of integration with TagSEA (or other efforts in the code annotation area) is possible and promising for the future.

I also discussed with my mentor some issues about OSGi, Maven and other provisioning systems seamless integration in the framework-to-be, since they share most of metadata and semantics about components: it would be nice to have a core set of shared essential metadata.

I am currenty thinking - and discussing with my mentor - about the chance of extending an existing OSGi Bundle Repository implementation, to add the needed semantic services, avoiding to design the repository from scratch (thanks lemmy). The repository could be deployed as a bundle itself. However, this requires me some time to be assessed more thoroughly.

Repository coding will start thru next weeks, as soon as I decide existing components' and technologies' integration, analyze use cases and define a strategic architecture to rely upon.

I keep updating my project's wiki quite frequently; I just added identified use cases, outlines and specifications will follow asap.

Feedback, criticism and suggestions are welcome ;) .

status, Support seamless debugging between JDT and CDT

Hi all,

My project goal is to support seamless debugging between JDT and CDT. My project is mentored by Philippe Ombredanne. During these first weeks I have done the following things:

1 - announced the project : I created my wiki page[1] and a blog[2]. I sent emails (for instance to the cdt-dev mailing-list) to get suggestions, comments, and feedback.

2 - got the existing work : I got a link[3] from cdt-dev guys to a presentation on the several approaches to provide seamless debugging. My mentor gave me too some links[4, 5, 6] on how to debug Java JNI application.

3 - read documentation : I read documentation on the Eclipse architecture, and did tutorials to learn to write plug-ins.

4 - started to code : I started to write a prototype plugin to validate an approach

Feel free to comment :)

[1] wiki page
[2] personal blog
[3] Mixed mode debugger prototype presentation
[4] Debugging integrated Java and C/C++ code
[5] Debugging integrated in Eclipse
[6] Java and C/C++ JNI Application Debugging with GUI

status, Eclipse Web Interface

Hi all,

Here is a quick update on the status for the "Eclipse Web Interface" project.

So I have begun discussing ideas with my mentor, Nick Boldt, for the project and from this we have successfully been able to start narrowing down what the project's primary goal should be. During these discussions I have been keeping note of what I need to familiarize myself with -- right now the Eclipse Plug-in architecture is at the top of my list. Consequently, I've been getting my feet wet by starting to read the pertinent documentation on eclipse.org as well as playing around with some EMF tutorials and the Eclipse Plug-in Project wizard.

I have yet to officially start coding on the project itself, but this will be the next step! :-)

status, IDE Generator (Miguel Garcia)

Hi,

I see my SoC project comprising several areas, and thus I’ll report status in each:

1. the promotion area: I’ve started a blog
   DSL Tooling, with a touch of Language Engineering
   where I’m keeping a trail of design decisions, related know-how, and (soon) reflections upon particular code snippets. All this aiming to make life easier for those wanting to join the project, or simply start a related project.
   
   
2. the IDE generator itself (i.e., my pumped-up version of Gymnast)
   
   2.a) A small step next week: Ecore-ifying the APIs being generated as of now for Concrete Syntax Trees.
   
   2.b) In parallel, I guess I should start with IP issues around placing in the Incubation CVS the Gymnast code, I’ll contact my mentor on this but I understand completing the paperwork is on me
   
   
3. generating an IDE as a proof-of-concept. Alas, again two lines of activity here:
   
   3.a) there’s a favorite DSL IDE among those which I’m targeting, which is Emfatic, with several extensions already coded manually. The strategy is to harvest from them best-practices to embed in the generator. But in all honesty, the functionality that Emfatic sports is not (and will not) remain limited to what the pumped-up Gymnast generates. It’s a special status that Emfatic has among the “generated IDEs”. Before making this Emfatic into CVS, I need two weeks to solve some architectural issues (mostly, truly supporting editing several docs at the same time)
   
   3.b) No progress so far on a DSL other than Emfatic (I'm not thinking at this stage about coding, but about language design to pave the way for generation time), but I’ll hint at ideas all along in the blog. I hope someone picks up on that, for further impact.
   

Questions / comments / feedback are welcome!


Miguel

Calling all artists

The Google Summer of Code (SoC) program [1] is underway and Eclipse has over 20 projects [2]. SoC, which is sponsored by Google, provides funding for students to work on open source projects over the summer. We (the students) submitted proposals which were reviewed by several Eclipse committers (and many of your favorite evangelists). While the program is sponsored by Google, the management and mentoring is done by the Eclipse community. For the past month many of the students have been getting involved with their projects, meeting people on mailing lists / newsgroups, getting access to the code, etc...

[1]http://wiki.eclipse.org/index.php/Google_Summer_of_Code
[2]http://wiki.eclipse.org/index.php/Google_Summer_of_Code_2007

We have also been working on a logo. Gen Nishimura has submitted some nice artwork, but I'm sure others have creative ideas too. If you have any ideas please take a look at bug# 184913 [3].

[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=184913

Finally we (the students) will be using this blog [4] to update the community on our progress, solicit ideas, etc... Over the next few days some of us will outline what we have been up-to and how we are proceeding with our work.

[4] http://eclipse-soc.blogspot.com/

Eclipse SoC

Eclipse SoC is ramping up and students are starting to get immersed in the Eclipse Community. For a complete list of projects that we are working on, please visit our wiki page [1].

[1]Soc Wiki Page

Some students have been involved in Eclipse for years while other students are relatively new, so any advice that veteran community members have is always welcome!