Have you tested Maven ? http://maven.apache.org
On Fri, 3 Sep 2004 09:26:37 -0700, Jim Barrows <[EMAIL PROTECTED]> wrote: > > > > -----Original Message----- > > From: Dan Allen [mailto:[EMAIL PROTECTED] > > Sent: Friday, September 03, 2004 9:17 AM > > To: Struts Users Mailing List > > Subject: [general] managing common files > > > > > > > > The response I most anticipate is to have a target in build.xml that > > reaches out to a common directory and pulls the newest version into > > the project tree. Then the common folder will have its own CVS module > > and all updates to such common files should occur only in the common > > folder and not on the file inside of the particular project which uses > > it. Running the target allows a project tree to be brought "up to > > date" ready for export as a standalone project tree. > > > > Am I on the money or is there a better way to handle such resources? > > You're close... the problem is that what happens if one project has to customize one > of your base files? Your ant task needs to be smart enough to not stomp on that > customization. Then there's question of is the pain of managing "common" files > really worth it? > > I've found that trying to manage common files across projects is usually more pain > then it's worth in a lot of ways. I typically use either appfuse, or one of my base > project setups as a template to get started, and then just don't manage the common > files anymore. Each project gets updated as it needs it. > > When I go to shops where they try and keep all the common files together, I've > noticed that they start running into a LOT of classpath issues, and other conflicts > that I just don't deal with because I don't try and gather things together. The > shops generally claim it's easier... until we start comparing set up times and > deployment times. I generally can just war up my project and drop it off on the > server, while they have to tinker with it until all the libraries are correct. Or > worse, they can't upgrade to some new version, because it (the new jar version) will > break their old code, so they end up having to reinvent the wheel. > > Since a WAR file is supposed to be a self-supported unit that doesn't need anything > else, I try to keep it that way. If I can't just drop it off on the server, I > usually find myself with more headaches then I really care to deal with. > > > > --------------------------------------------------------------------- > 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]
