Hi, from my experience with maven I can offer you the following hints/thoughts:
o Try to decouple your modules by changing them into Avalon components. We are using the lightweight component framework of Apache's Avalon (http://avalon.apache.org). An Avalon component consists of an interface and its implementation(s). The interface is put in one Maven project, each implementation is put in a Maven project of its own. So dependencies of components are merely dependencies between Avalon interface projects (but never of Avalon implementation projects). Avalon interfaces are supposed to be quite stable, so changes occur very rarely. If you have to fix minor bugs only the implementation project will be concerned and you don't have to rerelease all dependent projects (because the dependent projects only depend on the interface project). o In addition to the Maven interface and implementation projects there are integration projects which depend upon both interface and implementation projects. For them your observation is true. Minor bug fixes in an implementation projects force you to rerelease the integration project. Integration projects are usually large project with a lot of dependencies. Integration projects are usually customer projects. o So we start to implement integration projects and try to decouple the modules aka components within the project as best as we can using Design Patterns or similar stuff. Of course the integration projects can grow quite fat. But after a while the Avalon interfaces show up and stabilize. Then it's time to factor them out into projects of their own. The interface is shifted to an interface project, and the implementation to an implementation project. Both are dependencies for the integration project now. You may work with Maven's SNAPSHOT feature for a while, if the implementation proves to be fragile and change-prone. o What happens now if there is a minor bug fix? Of course the concerned implementation project/module must be fixed and rerealesed, the integration project using that implementation project now depends on the new version and must be rereleased. *But* none of the other projects/modules must be touched even if they depend upon the fixed project's interface. So decoupling of modules/components with Avalon can mitigate the described problem considerably (although it might not solve it in every situation). Regards Holger > -----Original Message----- > From: Julien Stern [mailto:[EMAIL PROTECTED] > Sent: Friday, May 30, 2003 3:42 PM > To: Maven Users List > Subject: Managing releases with large projects under Maven > > > Hi all, > > We are now using Maven for all our builds and have just been running > into the following problem: > > We have about 30 mavenized modules, which are all built thanks to the > reactor. Naturally most of them depend on others. > > Each of the project.xml file is part of its corresponding module > (in the CVS sense). This seemed fairly natural, as one wants to be > able to compile each CVS module in a standalone way. > > Now, when we release one module, we tag the module in the CVS > (say RELEASE_1_2_3), and the project.xml file, being part of the CVS > module, is naturally tagged. > > Now, here comes the problem (well, you may call it a feature... ;) ) : > because the project.xml file is tagged and specifies all the > dependencies, we need to make a new release of a module each > time one of > the _DEPENDENCY_ of a module is released. > > This means that if we fix a small bug in one of the "core" module, > we have to recursively make releases for nearly all our modules, > even though no code has been modified in any of them, but only > to reflect the fact that the new "core" library should be used in the > project.xml file. > > I'm wondering if some of you have run into a similar issue > and how they > are dealing with it. > > Sincerely, > > -- > Julien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
