ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Scott Ganyo <>
Subject RE: File copy problem
Date Thu, 21 Feb 2002 21:52:53 GMT
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...


> -----Original Message-----
> From: Steve Holdener []
> 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:   
> <>
> For additional commands, e-mail: 
> <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message