2.3.0
This release enables Snipmatch to insert code snippets into arbitrary text editors. Special support (Java-specific template variables, Create Snippet context menu) for the JDT Java editor still exists, but snippets can now be inserted into other editors as well. The snippet’s author can restrict a snippet’s applicability to certain file types or extensions, thus making it possible to create snippets that apply, e.g., to *.xml files only. (Development of this feature was kindly sponsored by Alte Oldenburger Krankenversicherung AG.)
Moreover, this release enhances subtype-aware code completion to also boost local variables, fields, and methods if their type is a subtype of the current context’s expected type.
The project leadership certifies that the APIs in this release are "Eclipse Quality".
With Code Recommenders 2.0.0, the code base has seen a significant architectural redesign to cleanly separate UI from components useful in a headless environment. Compared to the 2.2.0 release, the 2.3.0 release has seen little changes, although a small number of UI-dependent utility functions have been made available in a standalone bundle that does not make any visible UI contributions itself.
Two architectural issues of the original 2.0.0 release remain:
- Code Recommenders uses Google Guice as its primary dependency injection mechanism; some extension have to be contributed using Guice Modules rather than using Eclipse extension points. In addition, Code Recommenders internally mixes Eclipse 4 and Google Guice DI for accessing preferences. For future releases we may investigate how to move from Guice to Eclipse 4 DI, but this would require a significant amount of work to be done in both Code Recommenders and E4 to support required concepts. This change is not yet on the roadmap for any future release.
- Code Recommenders uses Google Guava’s implementation of an EventBus instead of reusing Eclipse 4 IEventBroker. This is mainly because there was no reason to switch from Guava to the Eclipse implementation. This may change in future releases.
Code Recommenders does not handle personal information and does not share details about a user’s code with any entity on the web. Users should be aware, however, that by default Code Recommenders performs network I/O in the following cases:
- On start-up, Code Recommenders checks for updates of a model index file hosted on download.eclipse.org. If updates are available, a larger download (< 1 MB) is triggered.
- Whenever a library is accessed for the first time, Code Recommenders checks for updates to the respective recommendation models hosted on download.eclipse.org. If updates are available, a larger download (up to several MB) is triggered. Both update checks and downloads may leak information about the libraries used by a developer. To prevent this, auto-download mode can be disabled; model archives can still be downloaded upon explicit user request.
- Code Recommenders has the ability to query Maven Central in order to identify a library used by the user. To do so, a cryptographic hash will be send to a server not hosted by the Eclipse Foundation. By default, this ability is not used; it must be explicitly enabled by the user.
- On start-up, the optional Snipmatch component pulls snippets from a Git repository hosted on git.eclipse.org.
- Due to its nature, Code Recommenders’ log messages often refer to portions of the user’s code. If the user makes use of the Eclipse’s Automated Error Reporting facility, he or she should take care to read and, if necessary, sanitize the error report before sending.
If the user works in a severely restricted environment with limited or no Internet connectivity, Code Recommenders and its recommendation models can be downloaded and installed at once. The project website provides instructions for this use case, which is expected to be rare, however.
By default, Code Recommenders uses no cryptography. However, recommendation models or snippets may be served by HTTPS if the remote server supports this.
Wherever possible, links to web pages (e.g., documentation) from within Code Recommenders use HTTPS, not plain HTTP.
- User Documentation: The current project website (online since December 2013) contains a short Getting Started guide, an extensive Manual, and a FAQ. The project website is linked to on the Welcome to Eclipse view shown after installation. Several subpages (manual, FAQ) are linked to from various places in the software (dialogs, preferences).
- Localization: As of Eclipse Kepler, Code Recommenders is fully internationalized and relies on the Eclipse Babel project for localization. Internationalized resource files have been made available to the Babel project from Code Recommenders 2.1.13 on (released 23 March 2014).
- Build system: Code Recommenders is build with Apache Maven and Eclipse Tycho. It makes some use of the Common Build Infrastructure (Gerrit, Hudson, signing webservice), but does not (yet) inherit from the CBI’s parent POM. To ease initial project setup, Code Recommenders uses Eclipse Oomph both for the main project and its incubator projects.
- Developer Documentation and Code Examples: Code snippets showcasing how to use the low-level headless APIs introduced with Code Recommenders 2.0.0 are kept with the source projects. They should provide sufficient information on how to integrate additional recommendation engines with Eclipse Code Recommenders or how to obtain recommendations using the headless API. The Jayes Bayesian network library part of the Eclipse Code Recommenders project is featured on the project website and has furthermore been documented in an extensive blog post.
Code Recommenders 2.3 is stable and designed for daily and frequent use. It should run without any issues in terms of performance or memory consumption on standard development machines.
Subtypes-aware code completion maintains an index of the user’s project dependencies, which may take several minutes. This index is created on demand in a background thread, but only if the user expliclity enabled subtypes-aware code completion. (The user will be prompted to do during content assist the first time subtypes-aware code completion is applicable.)
All components of Code Recommenders 2.2.x are also part of the 2.3.0 release.
Not applicable.
The Code Recommenders projects interacts with its end users in various ways and places:
- Blog posts announcing new features of Code Recommenders occur infrequently. They are syndicated on Planet Eclipse.
- Short announcements are made on both a Google+ page and Twitter account. However, much of the communication happens over the project lead’s Google+ and Twitter accounts.
- The Eclipse Forum has never seen much traffic and is not used anymore. There exists an external support forum, which receives light traffic (1-2 questions/month).
- Bugs and enhancements are tracked and discussed in Bugzilla.
- Code Recommenders also solicits feedback on Uservoice and Stackoverflow. These sites are advertised on the Code Recommenders preference page and the Code Recommenders website’s community page, respectively.
The Code Recommenders project interacts with both its adopters and developers/committers through the same set of channels:
- The project’s developer mailing list is the primary instrument for coordination among developers. The list receives about 20 mails/month during the Google Summer of Code season and 5 mails/month during the rest of the year.
- Planning and prioritizing decisions are noted in Bugzilla by assigning target versions to the individual issues.
- Contributions are accepted through Gerrit only. Part of the code review are automatic integration tests on the project’s Hudson instance (HIPP).
- Blog posts on technical topics surrounding Code Recommenders in particular and Eclipse/OSGi development in general are published infrequently and rarely. They are syndicated on Planet Eclipse.
- As part of the Google Summer of Code 2015, the project has attracted one student contributor, who still makes small contributions to the Code Recommenders project. Reducing the number of mentored students in 2015 was a conscious decision of the project’s core committers based on the previous years’ experience.
- For the first time, two committers of the Code Recommenders project employed by Codetrails GmbH have received outside funding by a commercial adopter, Alte Oldenburger Krankenversicherung AG, to develop a new feature: making the Snipmatch snippet completion engine programming-language independent.
Code Recommenders coordinates itself with four other Eclipse projects: JDT, Aether, m2, and Mylyn.
- Regular testing against JDT milestones helped spot a performance regression in JDT (Bug 481223). Aside from that, the coordination between the project is mostly one-sided: JDT evolves and Code Recommenders adapts to it.
- As predicted during the Code Recommenders 2.1.0 release review, the coordination effort with the Aether and m2e projects has decreased in the past year. While both Code Recommenders and m2e depend on Eclipse Aether, Code Recommenders uses the artifacts supplied by the Aether project directly, whereas m2e uses a specially packaged artifact bundling Aether with various libraries from the Apache Maven project. As of this writing, the only known issue (rooted in Equinox) is Bug 465593, which affects users who install Code Recommenders, m2e and the (third-party) SonarQube plugin.
- Minimal coordination effort is required with the Eclipse Mylyn project, due to an (optional) integration of Eclipse Code Recommenders’ intelligent code completion engine with Eclipse Mylyn’s task-focussed UI. Since its release as part of Code Recommenders 2.0.7, this feature has required almost no maintenance effort.