Difference between revisions of "Google Summer of Code 2009 Ideas"

• ANTLR is more robust than JavaCUP
• It has great editing/debugging tools
• It's supported by a community

compare the semantic model, and show the differences through a 3D representation. This project is about integrating those tools and experimenting with such visualization (one can easily imagine a "Time Machine"-like view for his diagrams.

doing so its keeping processing data in memory (more important the models are, more memory is used). This project is about leveraging CDO and writing another implementation of match algorithm to be able to compare any size of model, even ones with millions of elements.

Several enhancements could be made, such as supporting diagrams with images.

It would be interesting to be able to serialize EMF models with it.See http://code.google.com/intl/fr/apis/protocolbuffers/

Pain point

Working on huge projects is a common task for many Java EE developers. Sooner or later the developer would fall in a situation where he or she needs to find an exact Java EE artifact by just remembering a portion of the artifact's name or description, but not the its exact location. In such situation the developer should try different methods of searching, including file search, full-text search, etc. It would be much more convenient if the IDE provides a Java EE metadata search.

Solution

We are all familiar with the Open Type and Open Resource index searches in the workbench and how useful they are when we try to quickly locate our files and Java classes in the huge projects we are working with. The Java EE perspective should naturally evolve these features to Java EE metadata index search, where developers can search for certain metadata in their Java EE projects.

This new feature should introduce new dialog box that looks similar to the Open Type and Open Resource dialogs. There should be a hotkey combination available that enables users to quickly call the dialog. Typing a portion of the Java EE metadata name or description should filter the available Java EE artifacts and assist the user choice.

Examples for Java EE metadata are:

• EJB beans
• Web servlets
• EJB references
• Security roles

There is a new Eclipse project proposed - EMF Index - that could help with the realization of this idea.

It would be useful if an EJB container is embedded in the J2EE Preview adapter, too. This will make possible EJB development "out of the box" the same way as web development.

There is a suitable embeddable EJB container - OpenEJB. There is a guide how to embed OpenEJB in Tomcat. So, it should be possible to embed it in a similar way in the Jetty web container.

In the end the J2EE Preview server adapter should be able to deploy and run WEB, EJB and EAR modules.

PostgreSQL support is minimal in DTP. Only connection profile is implemented, other needed functions are derived from Generic SQL support.

Stundents job would be to implement PostgreSQL specific loaders and models and based on that the student should start implementing DDL generator.

Brian Fitzpatrick has documented how to do some parts in his blog that can be used

Initial bugzilla proposal. ---

Customer explained how it would be nice to have a "blue-arrows" Toggle button feature parallel to the current "Yellow-arrows" Toggle button feature.Just like "Yellow-Arrows" button has the tooltip -- "link open editors with Navigator contents" , the "blue-arrows" feature can have the tool-tip "Link open editors with current logical hierarchy view item"

That feature will provide the following functionality : If the user clicks on an open editor , the focus in the project explorer will go back to the logical item in the hierarchy view under the Deployment descriptor (in its Sub-tree) rather than going to the file on the file-system in the "ejbmodule" - subtree (for eg. clicking EmpLocalhome.java in editor view should go to the "EmpLocalHome" logical entity being shown in the Deployment descriptor sub-tree. The Current "yellow-arrows" feature rather makes the focus go into the "ejb module" folder and focuses on the EmpLocalHome.java file itself. )

If the above "blue-arrows" feature is made availalbe the developer never has to leave the Deployment descriptor subtree during the entire EJB project development work flow. Currently , the "yellow-arrows" feature makes the focus go back into the "ejbmodule" folder containing the corresponding .java . In situations where the EJB project might contain 100's of EJB's inside them, "ejbmodule" might contain 1000's of files including the Deploy Code etc. The user then needs to scroll all the way up to the Deployment Descriptor sub-tree to go double-click and open any other logical view item ,say another Entity bean component (eg. LocalHome or home interface etc.) The customer complained that he ends up clicking on the "collapse-all" feature in this case there by losing the whole work-flow and then has to go back to the logical hierarchy view under the Deployment descriptor sub-tree to find a particular ejb component for editing.

---

This proposal opens the question for an extensible link with editor feature. There might be more then one model (eg resource model, Java EE model, WS model, Persistence Model) and the same editor could be linked to all the models. A solution is to make the whole link with editor very extensible with different models contributing to this extension. The models will have a priority and a shortcut could be defined to link with the next (by prio) model.

Even thought the feature request is in Java EE tools the solution will probably involve an "extensible part" in the platform ui and an "extension part" in Java EE tools.