As our plugin eco-system grows, we want to give developers the same experience they have come to expect from our IDEs. Today we are happy to announce the integration of the Plugin Verifier tool for the Plugins Repository. This will allow you to check the binary compatibility between the IntelliJ IDEA‑based IDE builds and the IntelliJ Platform plugins as you upload them.
This tool is useful as it allows authors to check the plugins against a specified range of [since : until] builds for the platform, and not just against the current version of their editor. This process is needed as sometimes the IntelliJ API changes between releases. In turn, these changes might lead to binary incompatibilities between the plugin and the target platform, and so lead to NoClassDefFoundError, NoSuchMethodError, and similar exceptions at runtime.
With the recent update of the Plugins Repository, you can see the results of the plugin verification for each update of an IntelliJ Platform plugin which has been uploaded to the Plugins Repository.
The results of the verification are available in the Update Details View.
This is how it looks for one of the latest Scala plugin updates:
You can view the compatibility report and dive into the technical information about all the issues found.
In addition to this, you can schedule verification for a particular IDE build.
Please report all the bugs and feature requests to the Plugins Repository YouTrack Project.
With the GDPR (General Data Protection Regulation) coming into action last week, in addition to some of the compliance-related changes which were introduced earlier, there has been a change to the way plugins and their updates are uploaded to the plugins repository.
From May 24, 2018, it is a requirement to specify a valid license URL for your plugins. Please provide a valid license URL for your plugins at your earliest convenience.
- A License URL for new plugins should be provided on the upload form.
- For existing plugins, it is not possible to upload a new update to the plugin unless the License URL is provided on the Edit Plugin page. If you are using an API to upload the plugin update and the license is not specified, an error will be returned until the License URL is provided in the plugins repository interface.
The owner or creator of the plugin decides what EULA (end-user license agreement) should apply to the plugin and its updates. Unfortunately, JetBrains can’t tell you what your plugin’s Developer EULA should say because it will largely depend on your choice of how to license the plugin, and how to use personal data, etc. However, we can give you some pointers, e.g., Open Source licenses and various independent EULA generators (not affiliated with JetBrains).
Should you have any questions, please ask them to us here in the comments, post them to @JBPlatform Twitter, or drop us an email at email@example.com.
As of today’s release, JetBrains Hub is used for a unified authentication in the JetBrains plugin repository. Hub is our user and team management solution that we utilize internally, and now it serves as a user and permission model for the plugin repository.
We have moved from the direct authentication and accessing user profiles via JBA (JetBrains Account) in order to provide seamless integration with other JetBrains tools that are already using Hub for authentication. In addition, we will be able to build some exciting features in the nearest future relying on the already available Hub functionality, such as API auth via tokens, groups of users, etc.
A new authentication method is already live on plugins.jetbrains.com, and we don’t expect any issues on your side, as it is connected to the previously connected authentication method.
Should you have any issues with accessing your plugins or comments, please make sure that you have your JBA (JetBrains Account) connected to the Hub Account in the Hub interface.
If you encounter any issues, do send them to us here in comments, post to @JBPlatform Twitter, or drop us an email at firstname.lastname@example.org.
JetBrains Hub is available as a product, too. Here’s where you can learn more about Hub.
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 the IntelliJ Platform – exporting editor colour schemes as plugins. That’s right, if you have a custom editor scheme defined, you can get your favourite 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.