Oh, its unfortunate that I have run across this interesting thread just now. I actually ran across the exact same issue. Here's what I did (note this may not be the most elegant solution, however, it worked well, and was the easiest to implement). Since you mentioned that this is merely for rapid development, it is presumed that you will eventually update everyone to the newest version.
I created an alternate repository named "TAG" (whatever your tag is) and pointed apache to it. For example, if your corporate repo is http://corp/repo1, then create another repository named http://corp/repo1-TAG, and continuum can build only specific projects that should be overridden. This repository was populated solely with a specific tagged cut of the code. Then your team can depend upon the repositories of both. When they point to Utility 1.0.0, they should pick it up from TAG. Now, in my defense, this strategy was employed to work on top of a very legacy build/deploy system that knew only of SNAPSHOTs (and nothing else... so its not really fair to even call it a versioning system). It sounds like you guys have an equally goofy system. Are you guys supporting legacy version in tandem? Meaning, do you branch 1.0 and continue working on it, and then also work on 1.1? This was actually our big problem. Eric On 4/4/06, Mang Jun Lau <[EMAIL PROTECTED]> wrote: > > Hi everyone, > > I just want to spark a discussion here on the list. I want to know if you > guys/girls have encountered a simliar problem to what I'm having now. So > here goes: > > At our company we have two J2EE applications that are fairly large with > many projects. We operate in a RAD/Eclipse environment with CVS as our > SCM. There are shared projects (e.g. Utility projects) between the two > applications. These shared projects are developed more or less separately > from the two main applications. It is ideal for the two big applications > to depend on the latest (i.e. HEAD) of the utility projects. However, > sometimes when deadlines are looming, and there's no time to test these > latest changes, one or both of our applications will want to depend on an > older, CVS tagged version of these utility projects. > > So the question is, how can I design my POM for these Utility projects so > that I can build the application despite using a CVS tagged version? > > What I have now: > - App 1 depends on Utility 1.1.0 (HEAD) > - App 2 depends on Utility 1.0.0 (old CVS tagged version) > - Continuum 1.0.2 > - Utility pom.xml at HEAD is 1.1.0 > - Utility pom.xml at tag is 1.0.0 > - both applications are in Continuum, modules are symlinked in CVS so that > Continuum can check them all out at once. Utility project included with > each application checkout. > > So really I guess that if there's a way to checkout an older version of > the Utility project but HEAD of everything else, then I'm fine. Is there > a way to do this? Or am I using Maven incorrectly? If I'm unclear, please > ask and I'll try my best to clarify what I have. > > Thanks so much. > > > _Mang Lau >
