The categories

Confluence plugins have different behaviour based on how they are loaded by Confluence. The plugins themselves are the same, but based on how they are loaded, they may or may not be upgraded, or may not be disabled, or may not be uninstalled. This chart should explain how plugins can be loaded by Confluence, and the ramifications for each choice.

The category any particular plugin is in can vary with Confluence version or circumstance. The examples mentioned here describe the way particular plugins are loaded by default in Confluence 2.8.

カテゴリ

説明

例

Static

cannot be installed or upgraded without a Confluence restart

 

Core

Included with Confluence and cannot be uninstalled. The classes and plugin.xml are not bundled into plugin jars, but mixed in with Confluence source on the main classpath. Additionally, the plugin.xml definitions are not called "atlassian-plugin.xml" as they are everywhere else, but are named for the plugin e.g., "basic-macros.xml". We would like to separate some of them out and turn them into Bundled plugins.

Admin Sections

WEB-INF/lib

Confluence also places some plugin jars inside WEB-INF/lib. They are inserted during the build process by Maven. These plugins, likewise, cannot be uninstalled. In ancient times, this was the only way to install plugins, so users are also free to install plugins here. We try to discourage them from doing so, however.

JIRA Macros; also could be anything

動的

the opposite of static, these can be installed/upgraded while Confluence is running

 

Bundled

Bundled plugins are included in a zip of jars called atlassian-bundled-plugins.zip which is on the main Confluence classpath, in a resources directory - specifically <confluence-install>/confluence/WEB-INF/lib/confluence-2.x.y.jar/com/atlassian/confluence/setup or <confluence-install>/confluence/WEB-INF/classes/com/atlassian/confluence/setup. At Confluence startup, they are extracted and copied into the $CONFLUENCE_HOME/bundled-plugins directory, from whence they are loaded. To remove a bundled plugin (you shouldn't normally have to do this), remove the plugin from the atlassian-bundled-plugins.zip file and the bundled-plugins directory, otherwise Confluence will just put it back in place on the next startup. In versions later than 2.6, you'll have to recreate the .jar file (if the jar file is from the lib folder) or recreate the zip folder(if its in the classes folder). Bundled plugins can be upgraded or disabled.

Clickr Theme

Uploaded

Installed by the user via the plugin repository or the Plugin Manager page. These plugins are stored in the database and then copied to the $CONFLUENCE_HOME/plugins-cache folder on each Confluence node.

could be anything

To summarise the relationships of categories in the table, all plugins are either Static or Dynamic. Static plugins can be further categorised into Core or WEB-INF/lib. Dynamic plugins are divided into Bundled and Uploaded.

Use of the categories in Confluence

Within Confluence, the Core and WEB-INF/lib categories are not actually named as such, and they don't map neatly to other names (though they do map, as will be explained). They are used here because of the logical distinction they provide.

In Confluence, some of the Core plugins are called "System". Plugins can be designated as "System" by adding a flag to the plugin manifest file. To do this, system=true should be added to the top-level atlassian-plugin element of the manifest file. The manifest file is generally called atlassian-plugin.xml, but it could have another name; the Core plugins' files do.

All of the Core plugins once were labeled as "System", but it seems the practice has faded over time. If a plugin is designated as "System", then it will not show up in the Plugin Manager page in Confluence and thus cannot be enabled/disabled. However, it will show up in the Plugin Repository Client, where it can be disabled; allowing disabling there is probably incorrect behavior.

Static plugins that are not marked as "System" (any remaining Core and WEB-INF/lib plugins), are simply called Static in Confluence. There is no way to tell the WEB-INF/lib and Core plugins apart from within Confluence. You just have to figure out where the classes are.

Members of the other specific categories - Bundled and Uploaded - can be determined. We can tell which plugins are Bundled and which plugins are Uploaded, so we know which plugins are Uploaded though this specific term is never used in the Confluence UI. Instead, they are called Dynamic.

Upgrading plugins

  • Core plugins cannot be upgraded.
  • WEB-INF/lib plugins can be upgraded by replacing the JAR in WEB-INF/lib and restarting Confluence.
  • Bundled plugins can be upgraded using the Plugin Manager or the Plugin Repository Client. A new plugin jar is uploaded and stored as a Uploaded plugin. Confluence compares the version number with the Bundled plugin and uses the newer.
  • Uploaded plugins are upgradable using the Plugin Manager or the Plugin Repository Client. When a new plugin jar is uploaded, the previous version is discarded from the database and the $CONFLUENCE_HOME/plugin-cache.
関連トピック

Removing Malfunctioning Plugins

Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.