Versioning for a set of plugin libraries that supports foundational concepts within various toolsets

Question

I have a foundational metamodel which I have implemented using Java interfaces which I can easily version using major.minor.bugfix.

I also have plugins that utilize these libraries to implement these interfaces for various supporting tools. I use Maven for build management. I am struggling with how to version these plugins.

There are various external tools which all subscribe to the basic metamodel. I create plugins for these tools using my foundational metamodel interface project which is tool agnostic. When it comes to implementing the tool plugins, I would like to find a way to version these plugins which holds to the basic foundational interfaces which they implement but also clarify the distinction of the tool plugins. The code base for these different tools is 90% similar.

In the past, I had for example a version of 2.2.1 for the foundational interfaces, and various tool plugins were named 2.2.1+c19.0.SP3, 2.2.1+c22.0.1 or 2.2.1+ea11.0.1 which correspond to implementing 2.2.1 of the foundational interfaces while also serving as a plugin for the various tool/version subsequent to the + sign. Unfortunately, this breaks the way that maven handles versioning as the supporting tool plugins would never be interchangeable.

It appears that the supporting tool plugins may need to be entirely new artifacts even though 90% of the code is the same. So, I would need a ToolC-v19.0.SP3 artifact, a ToolC-v22.0.1 artifact, and so on. Each with a version managed individually. If I support 4 tools, each with 10 of their own versions, this turns into 40 different artifacts, each with similar implementations of the foundational interfaces.

Here is a bit more detail:

I create plugins for various different UML modeling tools to allow for direct integration of different physics toolsets. The versions that I support are a function of customer demand. So, if I support 8 version of rapsody, 8 versions of MagicDraw, and 8 versions of EnterpriseArchitect, that is 24 plugins. WIthin each toolset, the plugins only slightly vary from each release. But this is not it, my plugins support integration of physics tools. So, the number of individual tools is quite large, as well as the fact that those tools themselves have version changes and updates. I do have all of the implementation code for the different architecture tools and physics tools in different libraries. But, in the end the actual plugins to the architecture tools will also use the various physics tool libraries. In the end, my core codebase for integration and delegation control uses major,minor.bug. ...but I also need to version the end plugins for each tool plugin and physics tool integrated. My options are to force the architecture tool and physics tool version to the front and possibly make the core code base use a - extension and then have that version, ...but that approach doesn't seem intuitive, as my customers will be more interested in the core version of the plugins implementation but of course also care about which architecture tool it supports and which physics tool is being integrated. For instance, if my plugins are 2.2.3 from a core functionality perspective, how do I also keep track io the fact that the plugin itself supports x.y.z of a certain architecture tool and facilitates integration with a physics tool of version a.b.c

I like how maven supports ranges, but even better would be wildcards listed in the POMs for version allowances.

My ideal would be a version like the following:

2.2.3-cameo19.0.SP3-stk11.6.1

In fact, I currently use the above versioning, but as I try to use more range matching with maven, I find that this breaks Maven's philosophy for versioning.

I would like to specify pom ranges for the 2.2.3, but also specify that the cameo and stk might be exact matches or ranges themselves. Even more ideal, would be the ability to treat everything delimited by the dash as separate ranges and not force the entire version to match from broadest to most specific. I would like broadest to most specific within each dashed range.

...any thoughts are greatly appreciated!

I am hoping that there is some approach which might help.

• freakish: 40 artifacts is not a big deal. The real question is: why are those in 90% similar? Or in other words: why can't you move that shared 90% into a separate library?
• Community: Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer.

Answer 1

There are two approaches to your problem with the largish number of artifacts, and you should use both in combination.

1. Reduce the number of versions that you support for each tool. Supporting 10 versions of a tool is a lot, so see if you can get an agreement from your organisation and the affected departments to reduce that number of versions to, for example, 3.

2. Make the process of creating a release and publishing on maven automated and scriptable. Then you can just call one script, tell it for which tools and -versions to make the release and sit back while all N artifacts are created and uploaded.

• Proud Papa: The plugin api's for the tools vary slightly from version to version. the differences are in the implementing plugin code. Having these as branches helps facilitate the examination of slight differences in the public plugin architecture.
• Bart van Ingen Schenau: @ProudPapa, nothing I said prevents you from using branches for the different tool versions.
• Proud Papa: So then how would you version them, assuming that the tool variations to the plugins are held in different branches. Without a different package namespace how would you version. ...and if you have a different package namespace that feels a bit strange for branches of the same source for an artifact.