IntelliJ 2018.1 introduces a new API that we want to make plugin authors aware of. We’re changing the way you retrieve Code Style settings (such as formatting options) so that you can provide a
PsiFile, instead of a
Project. The ultimate goal is to support different code style settings per scope, rather than per project (see IDEA-69685).
As a bonus, the new API provides a shorter form for getting code style. So, for example, instead of writing
CodeStyleSettings.getSettings(project).getCommonSettings(language) you can now simply write
We’ve just pushed a major naming change to the IntelliJ codebase. For years, we hadn’t set or followed any naming conventions for modules in the IntelliJ IDEA source, and things had gotten into a total mess (for example, we had a variety of names such as
lang-impl). As usage of IntelliJ Platform grows, this has been causing more and more problems.
So now we’ve finally put all names of modules in IntelliJ IDEA and IntelliJ Platform sources in order. This means that all 357 modules in the intellij-community project have been renamed.
This doesn’t affect binary distributions of IntelliJ-based IDEs, as JAR filenames haven’t been changed.
IntelliJ 2018.1 removes the support of svn integration via SVNKit. The library is also removed from the platform dependencies and is no longer available for plugins. Now a command-line svn client is the only way to integrate with svn and execute svn-commands.
We made our best to maintain compatibility, however, some breakages could not be avoided. API changes are described at http://www.jetbrains.org/intellij/sdk/docs/reference_guide/api_changes_list.html
Here is the list of the affected plugins known to us (plugins from the Plugin repository):
We notified authors and sent pull requests with required changes for the plugins, but it could happen there are some plugins outside the repository which rely on SVNKit. If you own such, please update accordingly.
SVNKit was removed due to several reasons, mainly because it is only used to work with old svn 1.6 working copy format, thus bringing a little value to our users.
The Plugins Repository serves more than 200,000 downloads of plugins every 24 hours, which can easily double or triple during the major releases. It was starting to become quite a challenge for us to keep, process and display all the data since 2012, which is when we started counting downloads continuously and keeping all the history.
As the IntelliJ Platform matured, the number of plugins and their downloads drastically increased. Our old statistics mechanism (keeping everything on the Plugins Repository web application side in a MySQL database) started failing us, and there were some drawbacks in the user interface and the calculations, as well as some performance issues.
As an effort to improve the experience, we have completely reworked the way we handle plugin downloads statistics. The major changes included:
- Using CDN access logs as the data source instead of an application-side event;
- Shifting ownership of the data to the internal JetBrains statistics team;
- Updating the user interface.
As some plugin developers and end-users noticed, there were some discrepancies in both total downloads counts and the detailed plugin downloads statistics available to plugin developers – there was an unusual spike of downloads at the beginning of January 2018.
We started investigating these reports on the morning of 8th January 2018 (CET timezone), and it was fully resolved by the end of the day.
Our investigation showed that our new statistics processing scripts didn’t survive the New Year due to a minor bug, and hadn’t been providing correct numbers from the 2nd of January 2018 onwards (adding the previous stats on top of the current day).
We quickly fixed the scripts and recalculated all the statistics for affected days. The issue should not happen again in the future.
In addition to the fix, we also prepared a “backup solution” as part of the Plugin Repository application. The backup solution allows us to “delay” statistics from a specific date so that it doesn’t break total download counters (which is the most significant impact, as this affects plugin recommendations). We will keep this backup solution in place so that it can be used instantly in case of similar issues.
Thank you for all your reports, and we are sorry for the inconvenience caused.
If you have any suggestions or issues, feel free to send them to us here in comments, post to @JBPlatform Twitter, or drop us an email at email@example.com.
Today, I’d like to highlight a small but very useful feature for IDEs based on IntelliJ Platform – exporting editor color schemes as plugins. That’s right, if you have a custom editor scheme defined, you can get your favorite IntelliJ-based IDE to export it as a plugin
.jar file, complete with plugin metadata, and upload it directly to the Plugin Repository for others to install and enjoy.
Historically, all libraries used for building IntelliJ have been stored, as JAR files, directly in the IntelliJ git repositories. This approach has several downsides, such as increasing the size of the git repo whenever we need to update to a new version. Also, who wants to manually manage dependencies and versions these days? We’ve recently made some changes to try and improve this situation.
Some good news for plugin developers – starting in IntelliJ IDEA 2017.3 EAP 173.2463.16, we’re introducing some improvements and fixes to working with test data. Let’s take a look at what’s new.
For those that don’t know, the IntelliJ Platform comes with a test framework we can use to test language features added by plugins. The tests themselves are functional tests – we run an in-memory, headless version of the IDE that can load test data, such as projects and source files, execute a feature on those files (such as highlighting) and then compare the output of the feature with known good files. If the files match, the test passes. If they don’t, the test fails. More details on this approach can be found in the SDK documentation.
The JetBrains Plugin Repository is an aptly named web service for hosting and finding plugins for IntelliJ-based IDEs and TeamCity, extending the functionality of the products with new features, such as new language, framework or integrations. It’s both a web site and a web service, with a rich front end for searching for new plugins, and an API, used from the IDEs to find and install plugins, and by plugin authors to upload new versions.
As various teams are working on many improvements to the extensibility and plugins at JetBrains, today we’d like to start publishing regular updates on changes introduced on the side of the plugin repository.
We’ve recently made some changes to how we build IntelliJ Platform, specifically in how we handle external dependencies, such as the Kotlin compiler.
IntelliJ Platform is the core code of IntelliJ IDEA, and powers all of our IDEs – IDEA Ultimate, WebStorm, PyCharm, Rider, and so on. It’s also an open source project, making up most of the IntelliJ IDEA Community Edition repo, and can be used to build your own IDEs that make use of IntelliJ’s editors, user interface and infrastructure for projects, rich language parsing, refactoring, navigation, testing and much more, just like Android Studio and the Cursive Clojure IDE do.
Of course, building a product as complex as IntelliJ IDEA Community Edition requires a number of external dependencies, such as the Kotlin compiler and plugin and JetBrains’ own version of the JDK, which contains important fixes for IntelliJ Platform.