Are you a CVS expert? This is a tough problem, but one that's potentially worth a thousand points to whomever can solve it for me.
I'm trying to come up with a workable scheme to manage multiple Java web applications using CVS. The problem is that they all share a few class packages (also used by a few non web applications), they share a lot of common class packages and JARfiles among themselves, and... all have different JSP output templates (surprise, surprise) at the top level.
The general directory structure is:
/sitename/docs/* (documentation)
/sitename/en/images/* (images specific to the site's English JSP templates)
/sitename/en/* (the web application's English JSP templates)
/sitename/es/images/* (images specific to the site's Spanish JSP templates)
/sitename/es/* (the web application's Spanish JSP templates
/sitename/images/* (language-agnostic images used by the site's English AND Spanish pages)
/sitename/index.jsp (the web application's default page)
/sitename/* (the web application's root directory)
/sitename/WEB-INF/classes/
core/* (classes in the core.* package)
/sitename/WEB-INF/classes/
more/* (classes in the more.* package)
/sitename/WEB-INF/classes/
tagz/* (the "Tagz" taglib, with both .class files AND the taglib's .tld file)
/sitename/WEB-INF/lib/* (.jar files used by the web app)
/sitename/WEB-INF/struts/*
(.tld files used by Struts)
/sitename/WEB-INF/struts-c
onfig.xml (Struts' config file)
/sitename/WEB-INF/web.xml (the config file for Tomcat)
/sitename/META-INF/* (more files used for deployment purposes)
where "sitename" is the module name basically corresponding to a unique collection of JSP templates and image directories located in the directories above and parallel to (but not within) /WEB-INF.
Conceptually, I see the following as separate CVS modules:
"core" -- used by other applications, not all of which necessarily want to check it out into the "core" subdirectory of "/WEB-INF/classes" (even if they DO want to check it out into a "core" subdirectory SOMEWHERE. However, most of the time, this module WILL be checked out into the "core" subdirectory of "/WEB-INF/classes"
"more" -- same situation as "core"
"tagz" -- same situation as "core", except it will always be checked out into "/WEB-INF/classes/tagz"
"everything in /WEB-INF except the classes subdirectory" as another module. Specifically, everything in the "lib" and "struts" subdirectories, as well as all the files in "/WEB-INF" itself (like web.xml and struts-config.xml). I'd prefer that this module NOT be named "WEB-INF" in the repository, simply because that would prevent this scheme from supporting more than a single distinct web application in any single repository. If it's necessary to create "lib" as a module, "struts" as a module, and stick the two *.xml files in a third module, then glue them all together with an entry in the CVS modules config file, that's OK.
Here's where it gets ugly.
"/sitename" is the example used above, but the real situation is for there to be "/site1/", "/stite2/", "/site3/", etc. All of which are IDENTICAL below WEB-INF, but have completely different files in the /en/, /es/, /images/, etc. subdirectories in the web application's root directory.
In other words, when somebody checks out the "site1" module from the repository into the "/site1" subdirectory, and then checks out the "site2" module from the repository, the contents of /site1/WEB-INF and /site2/WEB-INF will be identical... changes made the file /site1/WEB-INF/classes/cor
e/foo.java
will ultimately be committed to the "core" module with the expectation that the next time somebody does a CVS update for "site2", site2's copy of "foo.java" will be updated with those changes.
What I need:
I need guidance on creating the physical modules. In other words, should I...
* do a CVS import from WEB-INF of everything below it, and rely upon entries in the CVS repository's module config file to let me pull out the individual pieces (like "core" and "more") for other non-web applications that DON'T want them to check out into subdirectories of "WEB-INF/classes"?
* import the packages in "WEB-INF/classes" as separate modules named "core", "more", and "tagz", then move up to "WEB-INF", delete the "classes" subdirectory (since all of its contents are now in the repository as three individual modules), and import "WEB-INF" as another module?
* For that matter, what should I name the module created from the contents of "WEB-INF" that will permit it to be checked out into a subdirectory named "WEB-INF"... ideally, some name OTHER THAN "WEB-INF" so I can apply this scheme to other web apps in the same repository. I originally thought about importing it as "bigwebapp1/WEB-INF" during some earlier experiments, but then ran into problems getting bigwebapp1/WEB-INF to check out into /site1/WEB-INF (where "/site1" was another module in the repository).
* what should my CVS module config file look like. I suspect it's going to have lots and lots of dummy ampersand modules whose only purpose is to build up a directory layout for other ampersand modules.
I'm initially posting this as 500 points, but I'm actually budgeting up to a thousand for the person (or persons, if no single response is adequate, but two or more contributors answer the question together) who gives a great answer with enough detail to enable me to print out the instructions, follow them with minimal need to refer elsewhere for more information, and get it all to work with no major problems so that I can ultimately mount "site1" as a cvs filesystem in Forte (Java IDE) and have everything check out with the right structure to build and run, then mount "site2" as a cvs filesystem in a different Forte project and have it work too.
I've personally been using CVS for three years, but I've never attempted to use it for a scheme this ambitious or complicated. Up to now, everything I've done has been single modules intended to be checked out into a directory with the same name as the module itself and exist as an independent, self-contained universe -- sharing nothing with other modules.
