That might be fine except... 1) The files I'm copying are not necessarily class files (image files, resource files).
2) The files end up deployed in a web archive (WAR) where I don't have control over classpath order (they exist en masse in the lib directory). Unfortunately, I really need a more general solution... Thanks, Scott > -----Original Message----- > From: Steve Holdener [mailto:[EMAIL PROTECTED]] > Sent: Thursday, February 21, 2002 4:08 PM > To: Ant Users List > Subject: Re: File copy problem > > > Scott Ganyo wrote: > > I have a hierarchy of projects. Some of the projects have > duplicate files. > > I need to make sure that a given project can override its > ancestor projects' > > files even if the files are newer in the ancestor. I would > think this is a > > common problem in complex builds. > > > > The only way I've found to do this so far is to specify > 'overwrite="yes"' on > > all my copies. This is horrible for performance, though, > as some of my copy > > operations move over a thousand files at a time. It is a > shame that the > > copy task doesn't support the concept of "copy when > different date (or > > content)" instead of merely "copy when newer date"... > > > > Any suggestions? > > > I would recommend building all classes a given subproject > depends on as > a jar. As you build and deploy, make sure the classpath lists the > subproject's library(ies) first. The classloader will only > pick up the > first version of a class it finds. > > We've experienced a similar problem at my client. Personally, I feel > that having duplicate classes like this indicates a flaw in the > development process. If architectural/common code is > maintained by one > group, that group can develop a release schedule (yes, complete with > release notes) for their "product." The great part about > this is that > each of the projects using the libraries can pick and choose which > version is appropriate for them at a given time. For > instance, one week > before a big round of QA would be a bad time to have your libraries > updated on you. This approach should preclude the need for duplicate > class definitions. > > One caveat: In our case, a certain group has copies of the common > source code and insists that the architecture team can't facilitate > their requests quickly enough for this to work. If they > simply allow a > few developers to function as members of *both* teams, however, the > problem is greatly reduced. > > > -Steve > > > -- > To unsubscribe, e-mail: > <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: > <mailto:[EMAIL PROTECTED]> >
