Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Users List" <ant-user@jakarta.apache.org>
Message-ID: <FABBF873F68ED311BB35009027D39072CFF0E2@darth_bobo.etapestry.com>
From: Scott Ganyo <scott.ganyo@eTapestry.com>
To: 'Ant Users List' <ant-user@jakarta.apache.org>
Subject: RE: File copy problem
Date: Thu, 21 Feb 2002 16:52:53 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----_=_NextPart_001_01C1BB22.1D330690"

------_=_NextPart_001_01C1BB22.1D330690
Content-Type: text/plain;
	charset="iso-8859-1"

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:steveh@mail.amnesiac.net]
> 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:ant-user-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: 
> <mailto:ant-user-help@jakarta.apache.org>
> 

------_=_NextPart_001_01C1BB22.1D330690--