Just received a googlegroup mail that is too good to not share, from Don Brown, Atlassian’s engineer extraordinaire, and in his current incarnation, Atlassian’s
“remote app”, eh hem, PLUGINS 3 Framework Design Architect!
providing a single application development AND deployment framework for both on-premise and OnDemand instantiations of Atlassian’s platforms (i.e., Confluence, JIRA, etc.).
It was a riddle that rattled long and hard in recent months, and really since the release of Atlassian OnDemand (and months before … over a year ago!).
The answer: Introducing Atlassian Plugins 3 Framework!
While I could summarize, sometimes emails are left best in the perfect state that they came in as.
This is one of them.
From: firstname.lastname@example.org [mailto:email@example.com] On Behalf Of Don Brown
Sent: Monday, August 20, 2012 3:21 PM
To: firstname.lastname@example.org; email@example.com
Subject: Remote Apps is now Plugins 3
Over the next few months, the Remote Apps project will be transforming into Plugins 3, which is intended to be a complete replacement for Plugins 2. The scope of Plugins 3 has expanded past just remotely hosted applications, and now brings its permissions and (now optional) sandboxing capabilities to in-process plugins as well. We expect to deliver the first developer preview of this technology at AtlasCamp 2012 in September .
The backstory here is after our Summit 2012 presentation, we’ve been having a bunch of internal discussions as well as discussions with partners and existing plugin vendors about the capabilities and future of Remote Apps, and two limitations quickly stood out:
- Remote Apps isn’t on-premise friendly
- The sandboxing was too restrictive for many (most?) existing plugins
The first limitation was really the showstopper – if we encourage plugin vendors to write Remote Apps that can only work for OnDemand, 85% of our current customer base, the on-premise installations, won’t benefit, and worse, it could mean fewer and fewer plugins as developers won’t want to maintain two code bases. The technical problem with Remote Apps and on-premise is that, since all the code is running on a remote server, it requires the on-premise Atlassian product to be addressable from that remote server, which almost always means the on-premise instance must be open to the Internet. The only ways to get around this – some sort of reverse HTTP firewall-poking agent or locally installed Remote Apps – are not where we want to go.
The second problem of sandboxing is because Remote Apps was an all-or-nothing proposition. Your app had to exist fully in the UI sandboxes we had in place (IFrames or strict HTML sanitization). What we wanted instead was to expand the permission system to include permissions that would allow any plugin, in-process or remote, to be written, and therefore, ensure 100% of existing version 2 plugins could migrate.
The solution we decided upon is Plugins 3. With Plugins 3, you can write a single binary (jar file) and deploy that plugin locally (in-process as you do now) or remotely in a standalone container running on a platform like Heroku. Within the plugin descriptor itself, there will be information on where the plugin is hosted remotely if that installation method is chosen. Therefore, the developer experience is like this:
- Write a version 3 plugin
- Deploy to Heroku (or where ever) to support OnDemand instances using the provided standalone container
- Register in the Marketplace as supporting remote and local installations
When an OnDemand administrator clicks ‘Install’, they will have the plugin installed as a remote descriptor pointing at your remotely hosted instance. When an on-premise administrator clicks ‘Install’, the plugin jar will download and run in-process like before. In both cases, the same plugin jar that was registered in the Marketplace is used.
Foundational to Plugins 3 is the concept of permissions, where a plugin is required to declare what APIs, code execution privileges, or sandbox breaking capabilities it needs. In addition to the existing Remote Apps permissions, Plugins 3 includes additional ones like ‘execute_java’, ‘use_private_apis’, and ‘generate_any_html’. This provides Atlassian the ability to define which permissions are available to side-loaded plugins in OnDemand, which need curation in the Marketplace, and which are only available for on-premise installations.
In all cases, the OnDemand or on-premise administrator will have to view and explicitly approve the permissions before the installation can take place. This also means Plugins 3 will be able to support every current version 2 plugin with the quick migration step of adding permission declarations to the plugin descriptor.
However, if the migrated plugin is to be able to be executed by the container, significant effort, if not a complete rewrite, will likely be necessary.
- New permissions element in plugin-info in atlassian-plugin.xml
- New plugin module descriptors for each Remote App extension point
- Ability to use atlassian-plugin.xml instead of a Remote App descriptor, though the Remote App descriptor format is still supported
- New container for running a version 3 Plugin outside the product
- Set of services that are implemented in container and local versions
In the next few days, we will be merging this work, currently in the ‘p3’ branch, into master. I will also soon be publishing a Plugins 3 Tech Spec with a lot more detail than I’ve given here. I’m excited about this new direction as it will bring the benefits of Remote Apps to all plugins for both OnDemand and on-premise. Our goals are to make plugins secure, easy to write, and OnDemand-friendly, and the future looks bright.
Comments and feedback welcome!
Congrats Don and team.. let’s bring it on!
Thank you for your persistence to the problem — AppFusions can’t wait to get our integrations and applications into the plugin 3 framework — one by one, and more into OnDemand.
The journey continues, for the long haul!
See you at AtlasCamp!
Post by Ellen Feaheny, CEO of AppFusions.