1

I'm building a service oriented architecture composed (mostly) of Java-based services, each of which is a Maven project (in an individual repository) with two submodules: common, and server. The common module contains the service's interfaces that clients can include in their project to make service calls. The server submodule contains the code that actually powers the service.

I'm now trying to figure out an appropriate versioning strategy for the interfaces, such that each interface change results in a new common jar, but changes to the server (so long as they don't impact the contract of the interfaces) receive the same common jar.

I know this is pretty simple to do manually (simply increment the server version and don't touch the common one), but this project will be built and deployed by a CI server, and I'd like to come up with a strategy for automatically versioning these. The only thing I have been able to come up with so far is to have the CI server md5 the service interfaces.

Improve this question
2
  • Have the CI job build on code-commit (assuming you want to version every time any code is changed). You don't necessarily need to MD5 in that way. You can also use the CI build number for uniqueness and incremental value.
    – BrandonV
    May 28, 2014 at 16:46
  • @BrandonV I only want the version of the interfaces to change when there was an actual change to the interface. If the interface itself has not changed, there should be no reason for the clients to have any knowledge of a new implementation.
    – Colin M
    May 29, 2014 at 2:30

1 Answer 1

Reset to default
1

I would consider using the specification-version and implementation-version fields in the Manifest. Specification-version would increment on changes to the interface specification, while the implementation-version would increment on each build.

Typically specification-version would be something like 1.0 and the implementation-version would append something related to the build something like 1.0.3432.

Look at the way JST is versioned for an example.

In declaring your dependencies you likely want to avoid using exact match.

Improve this answer
2
  • I agree with the general approach, but I'm trying to come up with a more concrete way of making that determination on the CI server. I'm trying to figure out how to determine if a new implementation version is being used.
    – Colin M
    Apr 29, 2014 at 14:14
  • @ColinMorelli I believe the specification version may need to be maintained manually, as it may not be trivial to determine if the specification has changed. Implementation version would be incremented on build. If the interface packages are cleanly defined, it should be simple for the CI server to determine if any implementation classes have changed. Common jar build should only occur if there are changes to it's contents.
    – BillThor
    Apr 29, 2014 at 22:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.