This commit re-organizes the Spark code base into a Apache Maven-compatible struture.
The project in this commit can be used to create a working Spark instance, by executing:
mvn clean package
An assembly (tied to the package phase) is used to generate a distributable directory.
The includes EJ-Technologies install4j configuration file has been adjusted to reflect the changes, and can be used to generate most types of distributables. This requires the non-free install4j application to be installed at the host that executes the build.
The build currently misses all 'external' plugins. Work remains to be done to move that into a Maven structure. A future improvement to this structure could include splitting off the assembly part from the core module, into a dedicated module, that allows for easy inclusiong of plugin-module artifacts.
* SPARK-1791: Replace JTattoo source with Maven artifact.
The JTattoo theme can be retrieved as a Maven artifact. No need to include the original source code in Spark.
* SPARK-1791: Moved Roar plugin into Maven structure
This commit reorganizes the bulk of the code for the Roar plugin into a Maven structure. It is not a functional Maven module yet though.
This commit adds a parent project, that wraps the pre-existing 'core' module. It is expected that other modules (for example, plugins) are added to this parent project later.
The Travis Continuous Integration platform should no longer try to execute the Apache Ant script, that has now been replaced by the pom.xml files from Maven.
* SPARK-1791: Distributales should include plugins.
The earlier structure generated the Spark distributables from the 'core' module. This module did not contain optional features (notably: plugins). This in turn made it impossible to include those optional features in the distributables.
To work around this problem, the distributables are now created in a dedicated module (aptly named 'distribution'). This module defines dependencies and assembly references to other modules of which artifacts need to be included in the distributables.
As a proof-of-concept, the 'roar' plugin was re-instated.
* SPARK-1791: Removing Roar plugin Ant buildscript.
* SPARK-1791: Replaced lobobrowser with JxBrowser (eval)
The project for the embedded browser that we used, lobobrowser, is defunct. Maven artifacts are not to be found.
A possible replacement is JxBrowser (by TeamDev). This software is proprietary, but they do offer free licenses to open source software.
In order to evaluate wether we'd like to apply for one, this commit replaces lobobrowser with JxBrowser. An evaluation license is included, but will no longer be valid in 30 days from now.
* SPARK-1791: Moving Fastpath plugin from Ant to Maven.
* SPARK-1791: Moving Battleships plugin from Ant to Maven.
Note that the code does not compile properly (SPARK-1818). I have disabled the Maven module (and sent Wolf an email).
* SPARK-1791: Moving Growl plugin from Ant to Maven
This plugin probably won't work properly, as it depends on a native library. We would better use one of the Java implementations for the GNTP protocol instead (SPARK-1880), which should improve portability.
* SPARK-1880: Growl plugin should use java binding.
Instead of the old native library that was used, the plugin now makes use of a Java-based API.
* SPARK-1791: Moving Apple plugin from Ant to Maven.
* SPARK-1791: Moving Reversi plugin from Ant to Maven.
* SPARK-1791: Moving TicTacToe plugin from Ant to Maven.
* SPARK-1791: Moving Flashing plugin from Ant to Maven.
* SPARK-1791: Moving Google plugin from Ant to Maven.
* SPARK-1791: Restoring the internal 'idle' plugin.
The 'idle' plugin was an internal (in core) that was initially not migrated from Ant to Maven. It depended on both an unknown libary, as well as the 'phone' internal plugin, which had issues of its own.
This commit restores the 'idle' plugin, by providing a reference to the previously unknown library (JNA), and removing the dependency to the 'phone' internal plugin.
* SPARK-1791: Moving Jingle plugin from Ant to Maven.
As this plugin depends on the internal 'phone' plugin, which has issues, I've left the module out of the Maven parent pom.
* SPARK-1791: Moving TransferGuard plugin from Ant to Maven.
* SPARK-1791: Moving Translator plugin from Ant to Maven.
* SPARK-1791: Moving OTR plugin from Ant to Maven.
There's a compatibility issue with the third party otr library that is being used (Maven has a different version than the one that shipped with Spark). I've not included this plugin as a Maven module to prevent build failures.
* SPARK-1791: Moving Spelling plugin from Ant to Maven.
I'm unable to find the correct maven artifact for the jmyspell dependency. As a result, the Maven module for this plugin is commented in the parent pom.
* SPARK-1791: Moving SIP plugin from Ant to Maven.
This plugin does not compile properly, with the existing dependencies (and/or missing 'phone' internal plugin). It's maven module has not been added to the parent pom.
* SPARK-1791: Moving SystemTray plugin from Ant to Maven.
The directory in which this plugin lived was named 'linux'. This has been renamed to match the plugin name: 'systemtray'.
* SPARK-1791: Moving plugin Meet from Ant to Maven.
There's a compilation problem, for which the plugin has not been added to the parent pom.
* SPARK-1791: Removing directory that held binary builds for previously commercial plugins.
* SPARK-1791: Move plugin pom.xml boilerplate into one parent module.
The first draft of the Maven structure for Spark introduced a lot of boilerplate pom.xml content. In this commit, a new module is introduced that, when used as a parent module for a plugin, removes most of the duplication.
The parent provides:
- A dependency on Spark core
- The assembly-plugin, configured to transform a module (that has the correct sturcture) into a workable plugin jar.
Both the pom.xml file and the plugin.xml file define the plugin name, version and description. It is error prone to keep both files in sync. Instead, the plugin.xml file should be popluated from the data that is in the pom.xml file.
Maven resource filtering is employed for this purpose. The drawback of this approach is that the plugin.xml file needs to be a Maven resource, which makes it part of the jar file. This means that this file is included twice in each plugin: once in the 'outer' plugin jar file, and once in the jar file that contains the plugin's compiled sources.
When building, Maven will add the project name and version in the manifest of the jar. This manifest is now used when displaying the version number of Spark.
Unlike Subversion, Git does not have consecutive build numbers. I've removed that identifier from the Spark source.
Guus der Kinderen
Automatically assigned