You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Stefan Schulze <al...@gmx.de> on 2010/09/16 16:48:54 UTC
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Res: Buildmanagement-Strategy
Posted by Felipe Roos <fe...@yahoo.com>.
Hi Folks,
That's a very intersting conversation. Regarding "internal process", do you have
such things as internal releases and external releases?
If so, how do you manage your maven releases of "releases" and "snapshots"
during the qualification cycles?
Regards,
Felipe Roos
http://www.linkedin.com/in/feliperoos
Achar desculpas para os nossos
defeitos não nos torna melhores
----- Mensagem original ----
> De: Nayan Hajratwala <na...@chikli.com>
> Para: Maven Users List <us...@maven.apache.org>
> Enviadas: Quinta-feira, 16 de Setembro de 2010 13:39:16
> Assunto: Re: Buildmanagement-Strategy
>
> On Sep 16, 2010, at 12:31 PM, Stefan Schulze wrote:
> > Sadly it's not simply done by the proper maven strategy - it has to
>correlate to the SCM and some internal processes. :(
>
> Ahh -- the infamous internal processes. Perhaps you might find some help with
>that part of it over on the Scrum Development list
>http://groups.yahoo.com/group/scrumdevelopment/ :-)
>
> Good luck!
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
> For additional commands, e-mail: users-help@maven.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Buildmanagement-Strategy
Posted by Stefan Schulze <al...@gmx.de>.
Nayan Hajratwala wrote:
> On Sep 16, 2010, at 12:31 PM, Stefan Schulze wrote:
> > Sadly it's not simply done by the proper maven strategy - it has to
> > correlate to the SCM and some internal processes. :(
>
> Ahh -- the infamous internal processes. Perhaps you might
> find some help with that part of it over on the Scrum
> Development list http://groups.yahoo.com/group/scrumdevelopment/ :-)
I think these processes are just the smaller part of the problem. The big one is the integration with the SCM, I think.
Maven is a great tool to fullfill the first requirement, but the SCM is another important tool. And this is, what I'm worried about. :-)
Stefan
--
Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief!
Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Buildmanagement-Strategy
Posted by Nayan Hajratwala <na...@chikli.com>.
On Sep 16, 2010, at 12:31 PM, Stefan Schulze wrote:
> Sadly it's not simply done by the proper maven strategy - it has to correlate to the SCM and some internal processes. :(
Ahh -- the infamous internal processes. Perhaps you might find some help with that part of it over on the Scrum Development list http://groups.yahoo.com/group/scrumdevelopment/ :-)
Good luck!
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Buildmanagement-Strategy
Posted by Stefan Schulze <al...@gmx.de>.
Nayan Hajratwala wrote:
> > 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.
I planned to do it similarly to the approach you described above. Thank you for the detailed description of the procedure. I've never worked with releasing in Maven before, so I didn't knew exactly what to do. I just had a rough conception. :)
Sadly it's not simply done by the proper maven strategy - it has to correlate to the SCM and some internal processes. :(
For the beginning, I would be happy if I could integrate this maven strategy cleanly with the SCM.
Stefan
--
GRATIS: Spider-Man 1-3 sowie 300 weitere Videos!
Jetzt freischalten! http://portal.gmx.net/de/go/maxdome
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Buildmanagement-Strategy
Posted by Nayan Hajratwala <na...@chikli.com>.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
Re: Buildmanagement-Strategy
Posted by Ron Wheeler <rw...@artifact-software.com>.
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
RE: Buildmanagement-Strategy
Posted by "Yanko, Curtis" <cu...@uhc.com>.
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:algroth@gmx.de]
Sent: Thursday, September 16, 2010 10:49 AM
To: users@maven.apache.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org
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: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org