On 16/09/2010 10:48 AM, Stefan Schulze wrote:
Hi,
My problem is not really only about Maven, but more about a general
buildmanagement-strategy using Maven. I didn't found a mailinglist or newsgroup
dedicated for general buildmanagement-topics, so try to post my issue in this
list.
I'm quite new to buildmanagement and have to think about a concept to support the
evolutionary architecture (or better "evolutionary development of the
architecture") we want to employ in the future of our product.
After hours and days of considering and contemplating we found two possible
solutions. Because both has serious drawbacks, I hope that anybody of you
already knows this scenario/requirements (I think it's not too unusual) or has
any suggestions to improve our solutions.
The requirements:
1) It is neccessary to support different modules (WARs) depending on the same module (JAR) in
different versions: 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. Some
time after release our customer wants to have an reporting-module, so wie 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. 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).
This is a common problem and when you quote the cost of reporting-1, you
need to include the cost of releasing booking-1 with the new core library.
You can reduce the cost by breaking core onto multiple smaller libraries
that are less susceptible to change.
With small changes to large systems, the cost of the release of a new
system can be larger than the programming and testing of the actual change.
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.
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.
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.
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.
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.
If any of you has some experience with similar requirements, has an idea for a
different solution or an suggestion to improve the one or the other solution, I
would really appreciate your ideas and comments.
You create releases that you store in Nexus (or some other repository).
In your SCM, you store your software with properly named branches so
that you can patch and rebuild anything that you have released.
Thanks for reading all of this quite long mail. :-)
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
