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).
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.
Thanks for reading all of this quite long mail. :-)
Stefan
--
GMX DSL SOMMER-SPECIAL: Surf & Phone Flat 16.000 für nur 19,99 Euro/mtl.!*
http://portal.gmx.net/de/go/dsl
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
