On Sep 16, 2010, at 10:48 AM, Stefan Schulze wrote:
> The requirements:
> 1) It is neccessary to support different modules (WARs) depending on the same
> module (JAR) in different versions:
That's good. Maven excels at that!
> For example, first we developed a module "booking" in version 1. Some common
> stuff is implemented in "core" (version 1, too), where booking-1 depends on.
Ok, so both of these should be *released* versions such that you can refer to
them in poms as:
<groupId>com.yourcompany.project</groupId>
<artifactId>booking</artifactId>
<version>1.0</version>
<groupId>com.yourcompany.project</groupId>
<artifactId>core</artifactId>
<version>1.0</version>
the pom for booking:1.0 would depend on core:1.0
> Some time after release our customer wants to have an reporting-module, so we
> develop reporting-1 and implement some improvements to core (because during
> the last project and in the meantime we saw, that there some decisions
> weren't ideal). So reporting-1 depends on core-2.
so you now release a new version of core, core:2.0. Both 1.0 & 2.0 should have
been deployed and should exist in your nexus repository.
booking:1.0 continues to depend on core:1.0
reporting:1.0 depends on core:2.0
> We do not want to upgrade booking-1 to use core-2, because in this case,
> booking would have to pass QA again (and the customer wouldn't pay this -
> there is no new feature).
There is no need to upgrade it.
>
> 2) It is neccessary, that it's possible to fix booking-1 or even core-1 (a
> bug in booking-1 is in core-1, in truth), although core-2 is the current
> version of core and booking-1 wouldn't even compile against core-2.
at this point the following versions have been released:
core:1.0
core:2.0
booking:1.0
reporting:1.0
the current development snapshots would be:
core:2.1-SNAPSHOT
booking:1.1-SNAPSHOT (currently depends on core:1.0)
reporting:1.1-SNAPSHOT (currently depends on core:2.0)
If a bug is found in core:1.0 which is causing problems with booking, you have
2 options:
Option 1:
* update booking:1.1-SNAPSHOT to depend on core:2.1-SNAPSHOT.
* Get everything compiling, etc with the new core
* Fix the bug in core
* release core:2.1 & booking:1.1
Option 2:
* branch core:1.0 to core:1.0.1-SNAPSHOT
* fix the bug in core
* release core:1.0.1 & booking 1.1
>
> The infrastructure:
> 1) We use Synergy/CM for version-control. For this case it's similar to
> Subversion with release-branch strategy. In opposite to Subversion, cheap
> and/or history-preserving copies are not supported.
Never used Synergy, so i don't have any comments on it.
> 2) We use Maven2 with an own Nexus-repository. Currently we use Maven and
> Nexus just to serve third-party-libs and to give the developers the
> possibility not to have to checkout the full source, but only these parts,
> they work with. So the repository isn't really part of releasing a new
> version of our system - we not even create a Release-version of our snapshots.
I think this is the big missing piece for you. In order to make your life
easier, you need to develop on SNAPSHOTs and release releases to Nexus.
> The (possible) solutions:
> 1) In each module are additional directories for the different versions. Each
> version-directory contains quite the same code (differing only in the changes
> made between the versions):
> core-
> |-1-src-...
> |-2-src-...
> ...
> This doesn't feel rights. It's somehow ugly, we copy code and we have to
> merge bugfixes manually from one version to all others. But it's a quite
> simple solution to solve both requirements.
Agreed that this is ugly and very error prone.
> 2) Each release-branch contains only the current version of code. The other
> versions are taken from the Maven-repository (in this case we have to use
> release-version and all the stuff). If a bugfix is core-1 is neccessary, a
> developer check-out the release-branch 1, implement the bugfix, start the
> build and calls a build- or release-manager to deploy the release-version to
> the repository. If it's time to go live with a new version, an appropriate
> assembly is built, which contains in parts of "fresh compiled" code and in
> parts of artifacts out of the the Maven-repository.
> At the detail, this is a quite complex approach. I don't really like, that we
> don't have a release-branch containing the full production-code - instead we
> would release a mixture of different release-branches.
This would all be resolved by using the proper maven strategy.
Hope this makes sense.
Good luck!
---
Nayan Hajratwala
http://agileshrugged.com
http://twitter.com/nhajratw
734.658.6032
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
