Plugin Repository Discussion

Enter your thoughts here...

Overview

Maven Repository as a Plugin Repository

The Maven project has a robust second-generation artifact repository system, licensed under the ASL 2.0 (which makes it a good choice to integrate into a commercial product).

The repository already gives us:

• Metadata-aware artifact repository (can hold xml's, jars, zips, you name it)
• Rich dependency mechanism w/transitive dependency resolution
• Repository aggregation, with support to read/write to Maven 1 legacy repositories.
• The obvious build system integration

Plugin Development

Maven 2 for new Plugin Development Kit

Maven 2 simplifies the process of building a plugin for Confluence by allowing the configuration & dependencies for a plugin to be pulled from a remote repository... and to be versioned, to easily allow a plugin to be built to support a specific version of Confluence.

Initially, the Maven 2 PDK prototype will include:

• Confluence 2.1 Plugin Parent module (support module)
• Example Plugin module

The support module will provide all of the dependencies, and build configuration, as well as the default configuration to deploy to the SVN repository (m1 & m2). Depending on the level of functionality of the SCM Wagon this may include manual svn steps.

Post prototyping, the PDK will include:

• PDK release assembly for standard and offline development; offline contains all the dependency jars
• Fully automated SVN deployment with SCM Wagon plugin
• Confluence 2.0, 1.4, ...??? support
• Maven archetype for creating new plugin modules

Maven Repositories for Contrib Projects

These are repositories for holding release artifacts for plugins that are hosted in the svn.atlassian.com repository. Plugin developers will need to deploy artifacts to one of these (depending on the version of Maven they are using) instead of checking in jar files under their plugins tree (as is the case now).

Maven 1

This is a Maven-1 repository, suitable for artifacts that are generated with Maven-1:

• http://svn.atlassian.com/svn/public/contrib/repository/maven1

Plugins that are Maven-1 based will deploy here.

Contributors, please hold of on adding artifacts to this repository for now.

Maven 2

This repository is for Maven-2 deployment:

• http://svn.atlassian.com/svn/public/contrib/repository/maven2

Plugins that are Maven-2 based will deploy here and to the Maven-1 repository as well for compatibility.

Since Maven-1 cannot read the Maven-2 repository format, this is required to allow Maven-1 based plugins to access artifacts from plugings that are built with Maven-2.

Contributors, please hold of on adding artifacts to this repository for now. The process will be automated by the plugin development kit.

Plugin Management

A major advantage to setting up a Maven repository for contributed plugins, is that Confluence can then use that repository (or really any list of repositories) to locate plugings to install, or to identify when new versions of already installed plugins are available.

Other Repositories

Atlassian could host one or more repositores, say...

• One for non-open-source plugins from Atlassian themselves
• Perhaps another for other plugins that aren't in svn.atlassian.com, but where the author doesn't (or can't) host a respository for distribution.

Also, for local use... lets say you just downloaded a .jar from somewhere, or that is how your vendor distributes it. You can just use a local repository (ie. just another directory).

Confluence Integration

I (Dan Hardiker) believe that repository integration should be through a modified & improved /admin/plugins.action interface. One which adds the following functionality:

• Repository browsing through the categories for plugins, also enabling you to view the release notes and see statistics such as size and number of downloads.
• Each plugin version should define which Confluence version it known to work / be broken on. An "unknown" state is the default for the confluence builds which are undefined in the metadata. This means that by default the latest version of this plugin that is known to work on this version of confluence will be installed (older working versions should still be selectable, but not defaulted).
• Ability to install / upgrade plugins from the repository into their confluence install (ideally with WEB-INF and home dir deployment - notifying the user if a webapp restart is required).
• Ability to deal with dependancies (such as the utilities plugin, or the ical library) and install them as appropriate.

This one is quite important as it prevents masses of needless information being transmitted:

• Confluence should not connect directly to the repository, it should go through a Servlet/XWork Action somewhere which will filter the results to the version of confluence it is talking to. (e.g: Confluence talks to the Servlet passing it's build number, the servlet returns information relevant to the confluence version its replying to)

The middle-man application should feed off the metadata as defined in http://hardiker.wiki.adaptavist.com/display/PUBLIC/Plugin+Repository (subject to change - e.g. dependancy information needs to be added). The most critical information to this middle-man app being the /atlassian-plugin/plugin-version/product-versions element.

Plugin Repository Administration

Repository Selection

Confluence should expose a simple page to allow a set of Maven (1 or 2) repositories to be configured. Initially this could be done with a macro, using the page's properties to persist the configuration. Should allow configuration similar to what is available in the repositories section of the Maven-2 pom. Specifically:

• id
• name
• url
• layout

As in:

Plugin Selection

Initially, to keep things simple, just get input from the admin for the plugins they want to have installed. Data is based on the dependency section of the Maven-2 pom. Specifically:

• groupId
• artifactId
• version

As in:

Once this information is entererd, the admin can click an Find New or Updated Plugins button. That will then render a list of whats new and updated. Under the covers, this will attempt to fetch the pom for each of the plugins listed. The admin can select the plugins that they want to install, which will basically just copy the jars to confluence.home/plugings and then prompt the user to reload.

Eventually, more sophisticated handling could be done... like:

• Check some metadata in the pom for Confluence compatibility (like is the plugin compat. w/2.0+, etc)
• Download install dependency plugins/libraries (like for example, many plugins require the Utilities Plugin).

Could also potentially make use the the SNAPSHOT feature of the repostiory, to always pick up the latest version. BUT, this would only be for convienece of the admin, Confluence would not attempt to install a newer plugin automatically, the admin must always go an Find New or Update Plugins.

Dependancies & Class Loading

Related to this discussion is the ponderance on how to handle dependancies and how to make all plugins capable of being loaded in home/plugins. See Plugin Dependancies and Classloader Concerns for more information.