_Elena_Uve_Alamy.jpg?#)
.png?width=1920&height=1920&fit=bounds&quality=80&format=jpg&auto=webp#)
Versioning for a set of plugin libraries that supports foundational concepts within various toolsets
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.
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.
What's Your Reaction?
