Julien, Check out the thread with subject "component versioning and usage rationale."
I think I will end up using a combination of version number and SNAPSHOT to handle our similar situation. Here is a snippet from the above mentioned thread: A third approach if this is a team issue would be to work with SNAPSHOTS more during development. Your component might be eg 1.4.3, but the 'main projects' would depend on 1.4-SNAPSHOT (ie the latest 1.4) until release time, when you'd manually change it to 1.4.somethingmorerepeatable. This is possible with jars on ibiblio because I understand there's stuff up there maintaining links to snapshot versions - can anybody clarify this? However unless you have something which 'acts like' ibiblio you can't do this for your proprietary jars. So..... I've updated my repository webapp (attached maven project) to respond to requests for 'somejar-9.3-SNAPSHOT.jar' (for example) with the most recently modified file matching the regexp somejar-9\.3.*\.jar (or the 'real' SNAPSHOT jar if it exists). This isn't ideal - it will get things wrong if eg you upload "1.4.1" after "1.4.2" - and wont play well with branches being developed simultaneously. However, it does let you specify a SNAPSHOT dependency without actually having a SNAP on the corporate repo. -----Original Message----- From: Julien Stern [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2003 9:42 AM 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]
