Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@jakarta.apache.org Received: (qmail 27547 invoked by uid 500); 18 Oct 2001 19:20:29 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Reply-To: ant-user@jakarta.apache.org Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 27535 invoked from network); 18 Oct 2001 19:20:28 -0000 Message-ID: <502326F46B08D41191C400508B6D70C10235C70E@ThisAddressDoesNotExist> From: Les Hughes To: "'ant-user@jakarta.apache.org'" Subject: RE: Identify which classes were created from a Java task? Date: Thu, 18 Oct 2001 20:19:59 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N True, of course there isnt a 1:1 mapping of source to class - which is why I mentioned as well. But Java really is a pain when it comes to trying to work out this kind of stuff esp. since javac does its own thing when compiling. I do wish it would only compile those files I tell it to....Hmm, jikes? Anyway here's a thought. What about having v1.0.jar of your system built and on the classpath for the compiler. Blow away your source tree and then sync out of your SCM only those files that changed post v1.0. Next compile this source tree and jar up anything it produces. Then stick this jar (v1.0patch1.jar) in front of the old one on the classpath and perhaps Bob's your uncle. Maybe? Or am I talking rubbish again and have I been doing too much powerpointing recently :-) Les > -----Original Message----- > From: Diane Holt [mailto:holtdl@yahoo.com] > Sent: 18 October 2001 18:00 > To: ant-user@jakarta.apache.org > Subject: RE: Identify which classes were created from a Java task? > > > --- Les Hughes wrote: > > Perforce supports labels and "what changed" kinds of > queries - others > > may be able to help out depending on your SCM. > > The problem with that approach is that Java can end up with more class > files than source files, so just having a list of which source files > changed (or even which files were handed off to the compiler) wouldn't > necessarily give you a list of all the build-output files > you'd need to > pick up. I think the "find -newer" approach is probably your > best bet (the > only other approaches I could think of were far more > inelegant than that > one, which is why I didn't offer any of them :) > > Diane > > ===== > (holtdl@yahoo.com) > > > > __________________________________________________ > Do You Yahoo!? > Make a great connection at Yahoo! Personals. > http://personals.yahoo.com >