Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 85267 invoked from network); 6 Feb 2002 17:05:44 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 6 Feb 2002 17:05:44 -0000 Received: (qmail 28616 invoked by uid 97); 6 Feb 2002 17:05:37 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 28564 invoked by uid 97); 6 Feb 2002 17:05:36 -0000 Mailing-List: contact ant-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Users List" Reply-To: "Ant Users List" Delivered-To: mailing list ant-user@jakarta.apache.org Received: (qmail 28553 invoked from network); 6 Feb 2002 17:05:36 -0000 Message-ID: <3C61625A.5060601@amnesiac.net> Date: Wed, 06 Feb 2002 11:05:30 -0600 From: Steve Holdener User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.7) Gecko/20011221 X-Accept-Language: en-us MIME-Version: 1.0 To: Ant Users List Subject: RE: inner classes References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Tue, 5 Feb 2002, hauke stammer wrote: >Compiling round about 2000 source files, Ant fails when running over >inner classes in one of our packages. This is just a suggestion, but I'd really recommend breaking the codebase down into more manageable chunks. We have also had some problems with a similarly-sized source tree, but it was even nastier. Jikes was, we believe, getting confused because of 1) the sheer number of classes, and 2) a lot of stupid dependencies resulting from poor design. The end product was a "successful" build with some corrupt class files. Problems showed up in DB access classes, for instance, and the WebLogic class loader would complain about botched *method names* that were a jumble of method declarations, random code, and string literals (SQL code in this case). Anyway, we're doing our best to break this down into subprojects, which should have been the approach in the first place. The idea is that each subproject team will release versioned, stable libraries to the rest of the project. My particular team's project is deployable by itself, so we should simply provide our latest stable ear file for integration testing. There are a *lot* of benefits to this approach, including faster builds, independent development/release cycles for the teams, and, of course, valid class files. :-) -Steve -- To unsubscribe, e-mail: For additional commands, e-mail: