Thoughts on the Maven migration

Openfire Openfire Dev
1

I’ve started to work on migrating Openfire from Ant to Maven last year, but eventually came to a point where this work stagnated.

This thread is to discuss the current status and ideas how to proceed.

What I’ve achieved so far:

  • Create different Maven modules (for core, for plugins, for web admin UI).
  • Determine the current dependencies Openfire is using and reference them from Maven Central. This went mostly well.
  • Configure Maven to build the documentation zip archive which can currently be downloaded from this site.
  • Configure the build to create a distribution folder, which contains all the dependent JARs and resources and the main jars (startup.jar, openfire.jar). The classpath is correctly set in the main jars, so you can do “java -jar startup.jar” and it successfully runs Openfire.
  • Configure the WebAdmin plugin, so that it’s correctly assembled and copied.

Known unresolved issues (what I’ve not achieved so far):

  • Some plugins (I remember kraken and stun) require non-public, homebrew or otherwise weird jars, which cannot be found on Maven Central (sometime not even on other places in the internet). Can probably be worked around by installing them in the local repo.
  • Plugins which don’t have web.xml require an empty one, because jetty-jspc-maven-plugin require an existing one in order to merge in the compiled JSP files (references). I think it can easily be solved by adding empty web.xml files. web-custom.xml was probably a workaround for a similar problem in the past and can later be removed.
  • tinder.jar (1.3.0) and i4jruntime.jar (probably not needed anway) are not on Maven Central. Currently referenced via system scope. You can only build the root currently, not single plugins or modules, because Maven cannot resolve the relative path then.
  • The Openfire directory structure needs to be restructured, so that it fits to the Maven structure (e.g. move src/java to src/main/java, etc…). I know these paths can be configured in pom.xml, but at least IntelliJ can’t import it properly then (although the plain build succeeds). So this point is strong recommendation.
  • Native installers: Actually the most intimidating issue, because it’s hard to develop and test.
  • The current Ant build script is configured to work with preconfigured igniterealtime servers (e.g. it references absolute path to some native install programmes like install4j)
    A developer usually only has one platform to develop on, so we would need some joined forces here.

For Windows we need to configure Maven to create a *.exe file using install4j or (as I suggested Inno Setup). Personally I develop on a Mac, so it’s not that easy to do for me.

For Mac: the current native build scripts are hard to understand, not documented, maybe outdated and probably hard work with (e.g. build/osx/dmg_openfire.scpt).

For Linux: personally I have no idea about it.

My thoughts on these issues:

  • Is the Mac installer really required in this complexity? e.g. do we need to install into the system pane?
  • We could consider javapackager tool to create native bundles. The downside is, that the UX might look/work different, but so what? The upside is, that you only have one configuration for all platforms.
  • After we found solutations for the plugins, missing Central jars and the installers, we should as last step change the directory structure.

Any thoughts, plans or volunteers to help?

2

Hi CSH,

Thanks for your effort to get this going again. As for the missing Tinder artifact: that’s something for me to pick up. I’ll make sure that that gets in.

As it is a lot more relevant here than it was in the original thread, I’m cross-posting a comment I made earlier. I can’t stress enough how important it is to facilitate organizations that have invested in setting up a Openfire-based project / development environment.

Please be aware that apart from regular “download-and-run” users, there is a very large number of projects that depend on the existing Openfire code base. Companies find ways to integrate with our product and/or our code base in ways that keep amaze me - and I only see a fraction of what people out there are doing. Ours is a pretty old code base: a lot of beautiful (and ugly) things have been created over time.

There are lots of organizations out there that depend on and/or have invested heavily in integration with our code-base: perhaps not in ways that we envisioned it, but those implementations exist none-the-less, providing value for their owners. It is too easy to think “gha, they’ll then have to stick with the old version, or re-do their integration” - we cannot do that. If we choose to turn things around, we must facilitate those people, and we must do so to a very long degree. We cannot apply “improvements” if that means that basically every integration has to be done over.

Whatever solution we find, it is important to be very, very conservative, be as backwards compatible as possible, and have a full set of migration aids (scripts, tutorials, etc) available. We will be applying a dramatic change (even when being conservative) - we should focus on limiting the impact as much as possible. This goes a long way down into nitty-gritty details. I am, for example, very wary of refactoring the directory structure to match the Standard Directory Layout. Yes, we’ll end op being more compliant to Maven, but it will make migration from the old code base to the new code base next to impossible for any larger project that uses something as simple as scripts to copy parts of our code. And that’s just a basic example.

I am, by the way, in favor of moving to Maven - that’s why I started the effort in the first place. However, we cannot treat this as a typical refactoring. Ours is an a-typical project: we’re very different from an in-house developed code stack, or a closed-source, over-the-shelf piece of software. Our software is open, widely distributed, and has a lot of legacy. That’s not bothersome bagage, that’s something to treasure.

We should come up with a complete list, but a few of the very basic items that we need to address are:

  • Can proprietary plugins continue to be compiled?
  • Code modification via our overlay mechanism, how will that be affected?
  • Will the original ant script still be available?
  • Will we have drop-in maven replacement for each target?
  • Project-migration documentation: how do developers move from an Ant-based Openfire project to a Maven one?
3

Huh,

proprietary plugins: The internal plugin structure won’t change, only the build tool. We would need to document, how to compile it with Maven.

overlay mechanism: I am not exactly sure, what it is and I didn’t put any effort into it. Good point, needs to be addressed, but I guess it can be done via Maven.

original ant script: If we change the directory structure it likely won’t run anways. So, in the longterm no.

drop-in maven replacement: Not sure what you mean, but my thought is that we roughly replace Ant targets with Maven profiles.

documentation: always nice :slight_smile:

Doing a Maven migration without changing the directory structure is a bad idea. As I said, at least IntellIJ has trouble with non-default structures, but having better IDE experience (project import) is one of the best argument for the migration.

Personally I don’t care that much about any old legacy integrations. Backwards-compatibility is nice, but sometimes you have to break it. Smack 4 breaks Smack 3 as well, which is fine imo. Other projects sometimes change their package names as well and it will break everything old.

My opinion is, that “they’ll then have to stick with the old version, or re-do their integration”.

Why can’t we do that? We are only very few developers doing work in our freetime and people should be happy if we move forward with a Maven solution instead of whining that their legacy integration doesn’t work with the latest OF version.

The migration alone is already very troublesome. It already took some weeks and will take further weeks just to have a workable (runnable) solution.

Providing extra solutions for any proprietary integration some company might have done is out of scope of the igniterealtime community imo, especially if we consider that it’s a free product.

We should probably first do the Maven migration completely except for changing the project structure. And when everybody is used to the Maven build (like 1-2 minor releases later), we should drop support for the old Ant script and change the directory structure.