I can't help but feel that you have completely obfuscated a relatively basic need. It's like you have the right tools but the wrong implementation.
Why doesn't storing your artifacts in Nexus also along with Maven POMs to specify the dependencies for each project work for you? ________________________________ Curt Yanko | Continuous Integration Services | UnitedHealth Group IT Making IT Happen, one build at a time -----Original Message----- From: Stefan Schulze [mailto:[email protected]] Sent: Thursday, September 16, 2010 10:49 AM To: [email protected] Subject: Buildmanagement-Strategy 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] This e-mail, including attachments, may include confidential and/or proprietary information, and may be used only by the person or entity to which it is addressed. If the reader of this e-mail is not the intended recipient or his or her authorized agent, the reader is hereby notified that any dissemination, distribution or copying of this e-mail is prohibited. If you have received this e-mail in error, please notify the sender by replying to this message and delete this e-mail immediately. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
