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