| <!-- |
| This document is provided as a template along with some guidance for creating |
| your project proposal. This is just a template. Feel free to change it as |
| you see fit (add sections, remove section). We feel, however, that the |
| suggestions represented in this document represent the reasonable minimum |
| amount of information to move forward. |
| |
| Please keep the formatting in this document simple. Please do not edit |
| this document in Microsoft Word as it adds huge piles of markup that make |
| it difficult to restyle. |
| |
| More information is available here: |
| |
| http://wiki.eclipse.org/Development_Resources/HOWTO/Pre-Proposal_Phase |
| |
| Direct any questions about this template to emo@eclipse.org |
| --> |
| |
| <html> |
| <head> |
| |
| <!-- |
| Include the title here. We will parse it out of here and include it on the |
| rendered webpage. Do not duplicate the title within the text of your page. |
| --> |
| |
| <title>Code Recommenders</title> |
| </head> |
| |
| <!-- |
| We make use of the 'classic' HTML Definition List (dl) tag to specify |
| committers. I know... you haven't seen this tag in a long while... |
| --> |
| |
| <style> |
| dt { |
| display: list-item; |
| list-style-position: outside; |
| list-style-image: |
| url(/eclipse.org-common/themes/Phoenix/images/arrow.gif); |
| margin-left: 16px; |
| } |
| |
| dd { |
| margin-left: 25px; |
| margin-bottom: 5px; |
| } |
| </style> |
| |
| <body> |
| <p>Code Recommenders is a proposed open source project under the <a |
| href="http://www.eclipse.org/projects/project_summary.php?projectid=technology">Eclipse |
| Technology Container Project</a>.</p> |
| |
| <!-- |
| The communication channel must be specified. Typically, this is the |
| "Proposals" forum. In general, you don't need to change this. |
| --> |
| <p>This proposal is in the Project Proposal Phase (as defined in the |
| Eclipse Development Process) and is written to declare its intent and |
| scope. We solicit additional participation and input from the Eclipse |
| community. Please send all feedback to the <a |
| href="http://www.eclipse.org/forums/eclipse.proposals">Eclipse |
| Proposals</a> Forum.</p> |
| |
| <p>This proposal is structured as follows. Section "Background" |
| gives the motivation of the project and provides some background |
| information about the origins of the proposed project, namely, the Code |
| Recommenders Project developed at Darmstadt University of Technology. |
| Section "Scope" outlines the initial set of tools and platforms this |
| project aims to deliver to its users; Section "Initial Contributions" |
| describes the current state of the project and the initial contributions |
| that will be made. "Description" gives little more details on the |
| intermediate goals. Section "Related Eclipse Projects" describes |
| potential future connections between current Eclipse Projects and the |
| Code Recommenders project as well as likely collaborations. The |
| remaining sections (Committers, Mentors, Interested Parties, Additional |
| Information) describe what their names suggest.</p> |
| |
| <h2>Background</h2> |
| |
| <blockquote><i>Under the right circumstances, groups |
| are remarkably intelligent and are often better than the smartest person |
| in them. - James Surowiecki: "Wisdom of the Crowds"</i></blockquote> |
| <br> |
| |
| <p>Application frameworks have become an integral part of today's |
| software development - this is hardly surprising given their promised |
| benefits such as reduced costs, higher quality, and shorter time to |
| market. But using an application framework is not free of cost. Before |
| frameworks can be used efficiently, software developers have to learn |
| their correct usage which often results in high initial training costs. |
| </p> |
| <p>To reduce these training costs, framework developers provide |
| diverse documentation addressing different information needs. Tutorials, |
| for instance, describe typical usage scenarios, and thus give the |
| application developer an initial insight into the workings of the |
| framework. However, their benefit quickly disappears when problems have |
| to be solved that differ from standard usage scenarios. Now, API |
| documentation becomes the most important resource for software |
| developers. Documentation is scanned for hints relevant for the own |
| problem at hand but if it does not provide the required information, the |
| most costly part of the research begins: The source code of other |
| programs is investigated that successfully used the framework in a |
| similar way. But learning correct framework usage from these real-world |
| examples is difficult. The problem with these examples is that they also |
| contain application-specific code that obscures the view on what is |
| really important for using the framework. This significantly complicates |
| the understanding process which makes the training a challenging and |
| time-consuming task again. However, source code of other applications |
| seems to be a valuable source of information. Code-search engines like |
| Google Codesearch or Krugle experience their hype not least because |
| existing framework documentation seems insufficient to support |
| developers on their daily work.</p> |
| <p>But despite their widespread use, it's an open question whether |
| code-search engines solve the problem of missing documentation in a |
| satisfactory manner. When looking at how developers use code-search |
| engines, it turns out that they rarely create a single query and study |
| just a single example; instead, they typically refine their queries |
| several times, investigate a number of examples, compare them to each |
| other and try to extract a pattern that underlies all these examples, |
| i.e., a common way how to use the API in question.</p> |
| <p>Although this task is very time-consuming, analyzing example code |
| seems worth doing. Apparently, example code must provide some important |
| insights in how to use a given API. Given this observation, the question |
| is raised whether such important information can be extracted from |
| example code automatically, i.e., without large manual effort. And |
| furthermore if valuable information can be found, how can these findings |
| made accessible to support developers on their daily work.</p> |
| <p>The <b><i>Code Recommenders'</i></b> project developed at |
| Darmstadt University of Technology investigates exactly these two |
| questions. In a nutshell, tools are developed that automatically analyze |
| large-scale code repositories, extract various interesting data from it |
| and integrate this information back into the IDE where it is reused by |
| developers on their daily work. The vision of the project is to create a |
| context-sensitive IDE that learns from what is relevant in a given code |
| situation from its users and, in turn, give back this knowledge to other |
| users. If you like, you may think of it like a collaborative way of |
| sharing knowledge over the IDE.</p> |
| <p>This Eclipse proposal is the next step towards the goal to build |
| next generation of collaborative IDE services, which we call "the IDE |
| 2.0" - inspired by the success of Web 2.0. The complete vision and |
| explanation of the IDE 2.0 to web 2.0 analogy is described in <a |
| href="http://code-recommenders.blogspot.com/2010/08/eclipse-and-academia-briding-gap.html"> |
| IDE 2.0: Collective Intelligence in Software Development</a> - published at |
| the Working Conference on the "Future of Software Engineering Research |
| (FoSER) 2010". |
| |
| |
| <h2>Scope</h2> |
| |
| One of the major goals of this project is to make a new generation of |
| tool ideas accessible and usable by the Eclipse community, to further |
| improve these tools based on the user feedback obtained or even to build |
| completely new tools based on the experiences and developer needs. So |
| far, a couple of steps towards IDE 2.0 have been accomplished, some of |
| which we will describe briefly in Section "Initial Contributions". These |
| tools, however, have to prove themselves as being useful. To allow this |
| evaluation this project aims to (i) provide a platform for innovative |
| IDE features that leverage the wisdom of the crowds, (ii) build a very |
| vibrant community around IDE 2.0 services based on Eclipse, and (iii) |
| provide an open platform allowing every community member to actively |
| contribute to these services and to build and evaluate new tools based |
| on the data contributed by the community itself. The initial scope of |
| this project is to provide tools for the following topics: |
| |
| <ol> |
| <li><b>Intelligent Code Completion Systems</b>:<br> |
| Code Completion Systems pretty good in showing a developer all possible |
| completions in a given context. However, sometimes these proposals can |
| be overwhelming for novice developers. Goal of this project is to |
| develop completion engines that leverage the information how other |
| developers used certain types in similar context and thus are capable |
| to filter OR rearrange proposals according to some relevance criterion |
| (similar to Mylyn's Context model but learning this relevance judgment |
| based on how thousands of users used a given API). <a |
| href="http://code-recommenders.blogspot.com/2010/05/its-all-about-intelligent-code.html">read |
| more...</a> |
| <li><b>Smart Template Engines</b>:<br> |
| The well-known SWT Templates are pretty helpful for developers not |
| familiar with all details of SWT. Unfortunately creating such templates |
| is a tedious and time-consuming task. Consequently the number of such |
| code templates is rather small. However, code of existing applications |
| contains hundreds of frequently reoccurring code snippets that can be |
| extracted and shared among developers. This project will provide tools |
| that support developers finding (for instance) method call chains for |
| situations like "How do I get an instance of IStatusLineManager inside |
| a ViewPart" and will allow them to share such templates with other |
| developers. |
| <li><b>Crowd-sourced and Usage-Driven API Documentation</b>:<br> |
| API documentation, independent of how much time has been spent on |
| writing them, lacks the information how developers actually use these |
| APIs. This information, however, can be easily extracted from code that |
| uses the APIs in questions, and thus could be used to enrich existing |
| API documentation with real usage driven documentation. Code |
| Recommenders aims to develop tools for finding and sharing this kind of |
| knowledge among developers. <a |
| href="http://code-recommenders.blogspot.com/2010/03/problem-of-incomplete-javadocs.html">read |
| more...</a> |
| <li><b>Stacktrace Search Engine</b>:<br> |
| Exceptions occur. Apache Maven, for instance, reflects this reality by |
| providing wiki pages for frequently occurring build exceptions which |
| aim to explain <i>why</i> these exceptions may have occurred during a |
| Maven build and <i>how </i> to fix them. This concept is a pretty neat |
| idea but its potential is not exhausted yet. Currently the matching |
| between an exception occurring during a build and a wiki page is done |
| based on the <i>type</i> of the exception (e.g., <i>BuildException</i>, |
| <i>IllegalArgumentException'</i>etc.) This matching is rather |
| coarse-grained and neglects the fact that the same exception might |
| occur in many different locations and may be caused by many different |
| reasons. First experimental results have shown that leveraging much |
| more information like the stackframe elements and exceptions messages |
| etc. yield to a system that is capable to find very similar exceptions |
| and thus allows building a new kind of search engine for stacktraces. |
| This project aims to develop such a stacktrace search engine and |
| provide integrations of this engine into existing web platforms like |
| the Eclipse forums and others. |
| <li><b>API Misuse / Bug Detector</b>:<br> |
| When using APIs unfamiliar with we often misuse a given API, i.e., we |
| forget to call certain methods or pass wrong parameters to a method |
| call etc. These mistakes are hard to find and debug. Tools like PMD and |
| FindBugs do a great job on finding issues like NULL pointers, or |
| recommend overriding hashCode along with equals but aren't a big help |
| if framework specific usage rules are violated. However, research tools |
| exist that are capable to find <i>strange</i> API uses, i.e., usages |
| which significantly differ from how <i>most people used a certain |
| API</i> and thus may indicate possibly bugs in code. This project aims to |
| provide an evaluation for such tools and will provide an initial system |
| as baseline. <a href="http://tinyurl.com/34lz56c">read more</a> |
| </ol> |
| <p>However, the scope of the recommenders project is not limited to |
| such kind of tools and encourages the community discuss new ideas of |
| tools that might be helpful for software engineers.</p> |
| |
| |
| <h2>Initial Contribution</h2> |
| |
| There are dozens of (research) projects that leverage collective |
| intelligence in one way or the other, and the code recommenders project |
| developed at Darmstadt University of Technology is just one of them. |
| However, an open vendor-neutral Eclipse project may be a perfect place |
| for these tools to contribute to Eclipse and to evaluate their |
| approaches within a vibrant user community. But every Eclipse incubator |
| project has to start with an initial contribution which will consist of |
| two existing recommender components. Each component was described in its |
| own blog post in detail, and we refer interested parties to these blog |
| posts and to the forum for further discussions of these tools. |
| |
| <ol> |
| <li><a |
| href="http://code-recommenders.blogspot.com/2010/05/its-all-about-intelligent-code.html">Intelligent |
| Code Completion</a> |
| <li><a |
| href="http://code-recommenders.blogspot.com/2010/03/problem-of-incomplete-javadocs.html">Extended, |
| usage-driven Javadoc</a> |
| </ol> |
| <p>Components like the <i>Stacktrace search engine</i>, or <i>API |
| Usage bug detector</i> are under development yet and will follow when ready. |
| </p> |
| |
| <p>The proposed namespace of the project will be <code>org.eclipse.recommenders.*</code>. |
| </p> |
| |
| |
| <h2>Description</h2> |
| <p>Goal of the (code) recommenders project is to build IDE tools |
| like intelligent code completion, extended API docs etc. that |
| continuously improve themselves by leveraging implicit and explicit |
| knowledge about how APIs are used by their clients, and, in turn, give |
| back this information to other developers to ease their work with new |
| and unfamiliar frameworks and development environments.</p> |
| <p>Current state of the initial contribution is that these systems |
| are fed more or less manually by an administrator that collects example |
| applications from large code repositories like EclipseSource's Yoxos and |
| then starts the analysis and data extraction process to build new |
| models. This approach may be further automated to leverage the already |
| existing infrastructure of the Eclipse Marketplace and P2 to |
| continuously scan and update API usages and build up-to-date models for |
| the Eclipse APIs.</p> |
| <p>Unfortunately, such a manual approach does not scale well if |
| potentially thousands of (non-eclipse-based) frameworks should be |
| supported. It is simply too difficult to find enough example |
| applications to make this approach work. Thus, in the long-term this |
| manual data collection process should be replaced by a community-driven |
| approach where users are allowed to voluntary share their knowledge |
| about how use these APIs either by giving explicit or implicit feedback |
| (cf. the <a |
| href="http://code-recommenders.blogspot.com/2010/08/eclipse-and-academia-briding-gap.html">position |
| paper about user feedback and information sharing</a>). Clearly, special |
| requirements for privacy have to be met so that no individual's private |
| or company�s critical data is collected or published. Different models |
| of data sharing have to be developed and discussed with the community.</p> |
| <p>As one of the first steps, a platform allowing developers to |
| share knowledge will be developed and the existing tools (i.e., |
| intelligent code completion and usage-driven Javadocs) will be based on |
| these concepts as a proof of concept. A community driven approach may |
| follow.</p> |
| |
| |
| <!-- |
| no legal issues |
| <h2>Legal Issues</h2> |
| --> <!-- |
| Please describe any potential legal issues in this section. Does somebody else |
| own the trademark to the project name? Is there some issue that prevents you |
| from licensing the project under the Eclipse Public License? Are parts of the |
| code available under some other license? Are there any LGPL/GPL bits that you |
| absolutely require? |
| --> |
| |
| <h2>Committers</h2> |
| |
| <!-- |
| List any initial committers that should be provisioned along with the |
| new project. Include affiliation, but do not include email addresses at |
| this point. |
| --> |
| |
| <p>The following individuals are proposed as initial committers to |
| the project:</p> |
| |
| The Code Recommenders project is developed at Darmstadt University of |
| Technology. The project is lead by Marcel Bruch and advised by Mira |
| Mezini. Although the number of initial committers is low, we expect this |
| set to quickly grow. The project itself was supported by more than 50 |
| students doing various hands-on trainings, bachelor and master theses in |
| the past and future contributions will be made directly under the |
| proposed project. Thus, the initial committers will be |
| |
| <dl> |
| <dt>Marcel Bruch, Darmstadt University of Technology</dt> |
| <dd>Project Lead</dd> |
| <dt>Mira Mezini, Darmstadt University of Technology</dt> |
| <dd>Project Management</dd> |
| <dt>Eric Bodden, Darmstadt University of Technology</dt> |
| <dd>Committer</dd> |
| <dt>Johannes Lerch</dt> |
| <dd>Committer</dd> |
| <dt>Dennis Sänger</dt> |
| <dd>Committer</dd> |
| <dt>Sebastian Proksch</dt> |
| <dd>Committer</dd> |
| </dl> |
| |
| <p>We welcome additional committers and contributions.</p> |
| |
| <!-- |
| Describe any initial contributions of code that will be brought to the |
| project. If there is no existing code, just remove this section. |
| --> |
| |
| <h2>Mentors</h2> |
| |
| <!-- |
| New Eclipse projects require a minimum of two mentors from the Architecture |
| Council. You need to identify two mentors before the project is created. The |
| proposal can be posted before this section is filled in (it's a little easier |
| to find a mentor when the proposal itself is public). |
| --> |
| |
| <p>The following Architecture Council members will mentor this |
| project:</p> |
| |
| <ul> |
| <li><a href="http://aniszczyk.org">Chris Aniszczyk</a>, Red Hat</li> |
| <li><a href="http://eclipsesource.com">Jochen Krause</a>, |
| EclipseSource</li> |
| </ul> |
| |
| <h2>Interested Parties</h2> |
| |
| <!-- |
| Provide a list of individuals, organisations, companies, and other Eclipse |
| projects that are interested in this project. This list will provide some |
| insight into who your project's community will ultimately include. Where |
| possible, include affiliations. Do not include email addresses. |
| --> |
| |
| <p>The following individuals, organisations, companies and projects |
| have expressed interest in this project:</p> |
| |
| <ul> |
| <li>Chris Aniszczyk, Red Hat</li> |
| <li>Fabian Steeg, University of Cologne</li> |
| <li>Benjamin Muskalla, Tasktop</li> |
| <li>Beyhan Veliev, EclipseSource</li> |
| <li>Holger Staudacher, EclipseSource</li> |
| <li>Zviki Cohen, nWire Software</li> |
| <li>Martin Robillard, McGill University, Montreal, Canada</li> |
| <li>Stefan Lay, SAP AG</li> |
| <li>Matthias Sohn, SAP AG</li> |
| <li>Frederic Madiot, Eclipse MoDisco</li> |
| <li>Maxime Jeanmart, JITT Consulting</li> |
| </ul> |
| |
| <!-- |
| <h2>Project Scheduling</h2> |
| --> <!-- |
| Describe, in rough terms, what the basic scheduling of the project will |
| be. You might, for example, include an indication of when an initial contribution |
| should be expected, when your first build will be ready, etc. Exact |
| dates are not required. |
| --> |
| |
| <h2>Additional Information</h2> |
| <ul> |
| <li><b>Blog</b>:<a href="http://code-recommenders.blogspot.com/">http://code-recommenders.blogspot.com</a> |
| <li><b>Project Homepage</b>:<a |
| href="http://www.stg.tu-darmstadt.de/research/core/">http://www.stg.tu-darmstadt.de/research/core/</a> |
| <li><b>Eclipselabs Project</b>: <a |
| href="http://eclipselabs.org/p/code-recommenders/">http://eclipselabs.org/p/code-recommenders/</a> |
| </ul> |
| |
| <h2>Changes to this Document</h2> |
| |
| <!-- |
| List any changes that have occurred in the document here. |
| You only need to document changes that have occurred after the document |
| has been posted live for the community to view and comment. |
| --> |
| |
| <table> |
| <tr> |
| <th>Date</th> |
| <th>Change</th> |
| </tr> |
| <tr> |
| <td>28-October-2010</td> |
| <td>Document created</td> |
| </tr> |
| <tr> |
| <td>22-November-2010</td> |
| <td>Updated Initial Contributions (added proposed namespace), |
| Interested Parties (added new interested parties), Mentors (added |
| second mentor), Committers (added three initial committers)</td> |
| </tr> |
| </table> |
| </body> |
| </html> |