I’m happy to announce that as of today, the Solace JMS API and Solace Java API are available directly through Maven Central. So if you use a central repository for java build dependency management, you won’t need to manually retrieve the .jar files from our FTP site and add them to your project. You’ll find everything you need here.
If you aren’t using Maven Central and prefer to download the .jar files from our FTP site or developer portal as you have always done, don’t worry, that option still exists.
For Java programmers who are using the OSGi framework, we have news for you too. Our JMS and Java .jar files are now OSGi bundles, containing all the necessary meta-data you need to use our APIs in those frameworks. This change in the .jar format is fully backwards compatible, so if you aren’t an OSGi user, the enhancement will be completely transparent to you.
Last but not least, anyone who’s been using our APIs for a long time will notice that with this release, we’ve gone from 4-digit release numbering, to a three digit semantic version number – namely 10.0.0.
You can find lots of discussion online about semantic versioning, but in a nutshell, semantic versioning allows an application programmer to identify in a project’s build dependencies the version(s) of the API acceptable to the application – even future versions that don’t yet exist! Semantic versioning imposes strict rules on when we are allowed to change digits in the future. The first digit must only change when a non-backwards compatible change is made to the API (we try very hard not to break backward compatibility, so we expect we’ll be at version 10 forevermore). The second digit changes when we add new features to the API, but don’t break backwards compatibility (you can expect that digit to increment every few months). And the third digit changes when we fix bugs in the API, but don’t add or change the existing functionality (hopefully, we won’t have to touch this one too often).
Why start at 10.0.0? First, we wanted a clean break from the previous version numbers, which were at 184.108.40.206. Second, we wanted API version numbers that were completely decoupled from our 4-digit release numbers since the 10.0.0 APIs work with any and all versions of our software and hardware message routers that are not end-of-support. Going forward, release notes for our VMRs and appliances will state the versions of API needed to take advantage of new features.
While JMS and Java are the first Solace APIs to adopt semantic versioning, over the coming months our plan is to adopt this convention across our entire set of messaging APIs.