> -----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]
