This commit started with the intention of adding a maxServerVersion attribute for plugins, but resulted in a partial rewrite. Changes:
- Removed the License enumeration - now, a simple string is used.
- Split off the admin console page that shows the content of readme and changelog files to a dedicated page, instead of plugin-admin.jsp
- Better define the difference between the plugin (human readable) name ("Avatar Resizer") and its canonical name ("avatarresizer")
- The admin console now shows plugins that have been downloaded/installed, but cannot be loaded. Where possible, an update is suggested.
- Support for maxServerVersion - plugins can now define a version of Openfire in which they will no longer load.

* OF-1342 Remove "Run Openfire" from the final step of the installer. Changed to "Start Openfire Service"

* OF-1342 Remove "Run Openfire" from the final step of the installer. Changed to "Start Openfire Service"

* OF-1349 Create separate Windows installer with and without JRE

This commit fixes a runtime problem caused by SortedSet usage with providers that are not Comparable. By using a different Set implementation, iteration order is predictable, without there being a need for providers being Comparable.

This commit adds some UX improvements to the 'edit group' page on the admin console.

Hopefully addressses UAC issues. Installs services on windows at install. Replaces launcher with starting service and launching web browser.  Adds option to create x64 installer for windows.

Attempt to address UAC issues with Windows. Installs services on windows at inst…

Hopefully addressses UAC issues. Installs services on windows at install. Replaces launcher with starting service and launching web browser.  Adds option to create x64 installer for windows.

OF-1336: Introduce UserPropertyProvider

By using a concatination of an interned string with another string, the resulting string will not be interned itself - making for non-functional lock.

These changes should be backwards compatible.

This commit adds a new feature to Openfire, that allows one to store user properties in an external system. This is quite similar to concepts like UserProvider, AuthProvider, GroupProvider, and so on.

The default behavior, moved from the User class to DefaultUserPropertyProvider, continues to use the ofUserProp database table. Provider implementations matching those of other types of providers have been added.

This commit allows a plugin.xml to use a reference to data defined in the pom.xml. This reduces duplicate data.

For instance, in plugin.xml, one could now define the version number by referring to the version number of the
maven artifact:

  <version>${project.version}</version>

Note that plugin.xml files that are processed using the old Apache Ant based build, will not be processed correctly.

This commit copies version number, author and description from plugin.xml to pom.xml. This makes the same information available as Maven metadata.

When Ant support is dropped, the duplicate data in the plugin.xml should be replaced by a filter (which takes the data from the pom.xml).

I continue to be thoroughly confused by having two directories per plugin, one for the plugin sources, and one for the maven build. This commit merges both directories.

As a side effect, various plugin unit tests are now executed by default. Some failed, for which I applied fixes.

This commit also adds some plugins to the Maven structure that previously were not.

* remove unused global.css

* OF-1334 Don't do CSRF check unless actions are requested

OF-1332 Update MySQL JDBC client to latest version.

OF-1310 Fix removal of last item of pubsub node

OF-1326: Improve sharing of the BOSH context

OF-1277 -- Change setting name to Invisible Login and Status

The Openfire plugin developer guide states that 'additinal' files should be in /classes/. Apparently, the old Ant script also included any files in the /src/. The new Maven structure does not.
To work around compatibility issues, code that was in /src/ is now moved to /classes/. This should work with both Ant, as well as Maven.

Additionally, this plugin now makes use of the new HttpBindManager API for registering contexts with the BOSH context. I do wonder if this plugin has any reason to be here though. Can't it just run its own embedded Jetty server?

Intead of using a parent context, a collection of Jetty handlers can be used to dynamically add/remove functionality to the BOSH context.

This commit replaces the parent context instance with a ordered list of handlers, which will attempt to process a request by:

1. Checking if this is a BOSH request
2. Checking if this is a request for BOSH metadata
3. Check if an extension was provided that can handle the request
4. Try to serve static content as a last resort.

In step 3, a collection of handlers is used, that can be modified at runtime. This allows plugins to register/remove handlers.

The entire collection of handlers (1 to 4) is maintained with a lifecycle that's different from the embedded Jetty server that uses them. This
allows the collection to survive a server reconfiguration, as well as act independent of the 'enabled' state of the BOSH service.

* OF-1325 -- Implement separate History settings in Client Control

* OF-1325 -- Implement separate History settings in Client Control

* OF-1325 -- Implement separate History settings in Client Control