Skip to end of metadata
Go to start of metadata

The issue we are aiming to resolve here is primarily how to releae multi-module products.

This includes:

  • management of parent version references
  • inheritence of the version from a parent
  • implications for source control

Management of Parent Version References

The current thinking on this is that in general the parent version will not be specified in the POM and that it will be located using the current search algorithm:

  • found inside reactor
  • found using USD
  • found using the RELEASE version mechanism (as for plugins)

This prevents the need to make changes consistently to that when the parent increments its version. At the point of release, the version will be populated with what was found at the time to make the build reproducible.

Inheritence of the Version from a Parent

While this was originally planned and executed on continuum and m2, among others, it proves problematic for making a release, and prevents making interim releases of individual components for patches or use in other applications (unless snapshots are used which is not particularly desirable as they haven't been properly promoted).

The planned approach is to:

  • version each component
  • set the product version on the project producing the actual assembly
  • release individually (ceonceptually, the tool can actually do them at the same time as a series of individual releases)
  • assist in syncing name using the release tool if that is the desired approach of the product (eg some products like geronimo want to keep the product version in all the JARs to be able to recognise where they belong)

Implications for Source Control

While making each module independant it has implications for tagging releases, and how checking out from source control works.

Desired outcomes:

  • checking out an individual module on its own will build correctly
  • being able to check out the entire source tree for a particular release and build in one
  • tagging an entire release correctly
  • tagging an individual module is possible
  • branching an individual module is possible

Checking out an individual module

This will build on its own since the parent is referenced using a repository location. However, if the version is omitted and RELEASE is assumed, then the behaviour between the search paths above is different (ie, in the reactor or USD you get the latest from your checkout, but when checked out on its own, you get what is in the repository as a release).

I believe this is not a problem, and that the behaviour can be expected. It should encourage proper releasing of the parent when it is changed.

Being able to check out the entire source tree, tags and branches

What this involves is for all projects to have a common root. Obviously if they are being built together with the modules definition then this will be the case. This also means that they need to be tagged together, and uniformly.

The assembly should also be made at the root and incorporate the modules at that point of time, otherwise the dependency versions could well be out of sync with what is tagged in the SCM.

This becomes a problem in subversion if the individual components have a trunk/branches/tags structure due to being tagged or branched separately. It is expected that the lowest point you would check out from will be the trunk/branches/tags, and those below cannot be tagged or branched.

  • Where should an individual create a branch or tag?
  • How is it different for other SCMs?
  • Does maintaining different branches (either via svn switch/cvs style or different paths in the checkout) affect the development cycle in a multimodule scenario?
  • If it is decided that a whole set of modules will only ever be tagged and branched together, is there any merit to versioning them together again then?
  • No labels

1 Comment

  1. Hi, I was looking for the best page to add my comment to, I hope this is the one (wink)

    With the scenario described above, it is not easy to use a module in multiple projects. In my opinion a module should be able to build without the notion of a parent. The module should describe which dependencies it needs and the minimum and/or maximum version of that dependency needed to build successfully. This way the module can be included in several large projects. At build time the master project creates a list of modules and versions of all the dependencies in the project and according to availability uses the latest versions when allowed, or earlier versions if limited by some module.

    This way it is possible to work on a single module in a large project, without the need to update versions in all other modules that need it. The latest version will be used automatically. Other projects can use and update the module as well.

    A downside of this approach is that you need to manage the module quality quite well, because of the chance of breaking other projects you are not aware of. To help this, only released stable versions should be used, the SNAPSHOT should be ignored for automatic inclusion.

    This is only useful for large projects where a lot of modules are being worked on and used in multiple projects. It would be good to combine this approach with some continuous integration tooling to make sure the latest and greatest versions all work well together.

    Chris