Return-Path: Delivered-To: apmail-jakarta-commons-dev-archive@www.apache.org Received: (qmail 37118 invoked from network); 29 Aug 2004 11:04:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 29 Aug 2004 11:04:23 -0000 Received: (qmail 73740 invoked by uid 500); 29 Aug 2004 11:04:19 -0000 Delivered-To: apmail-jakarta-commons-dev-archive@jakarta.apache.org Received: (qmail 73710 invoked by uid 500); 29 Aug 2004 11:04:18 -0000 Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Jakarta Commons Developers List" Reply-To: "Jakarta Commons Developers List" Delivered-To: mailing list commons-dev@jakarta.apache.org Received: (qmail 73696 invoked by uid 99); 29 Aug 2004 11:04:18 -0000 X-ASF-Spam-Status: No, hits=0.1 required=10.0 tests=DNS_FROM_RFC_ABUSE X-Spam-Check-By: apache.org Received-SPF: neutral (hermes.apache.org: local policy) Received: from [212.4.65.100] (HELO mail.datazug.ch) (212.4.65.100) by apache.org (qpsmtpd/0.27.1) with ESMTP; Sun, 29 Aug 2004 04:04:18 -0700 Received: from [192.168.123.84] [212.4.78.11] by mail.datazug.ch with ESMTP (SMTPD32-8.12) id A82F52CE010E; Sun, 29 Aug 2004 13:04:15 +0200 Message-ID: <4131B82E.9080008@yahoo.de> Date: Sun, 29 Aug 2004 13:04:14 +0200 From: "J.Pietschmann" User-Agent: Mozilla Thunderbird 0.7.1 (Windows/20040626) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jakarta Commons Developers List Subject: Customizing Jars was: Re: [lang] Interpolation References: <001b01c48cdc$80388ce0$d3409a51@oemcomputer> <20040829004829.52869.qmail@web50407.mail.yahoo.com> <41316661.5050709@apache.org> In-Reply-To: <41316661.5050709@apache.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N matthew.hawthorne wrote: > I see your point, but keep in mind that this was done to make the lives > of the users easier. Forcing a user to include a huge [collections] jar > for a project that only uses 1 or 2 classes from it doesn't seem > practical to me. Well, there's always the tradeoff between 1. providing many small jars, thereby creating lots of dependencies and making versioning hard, and 2. providing a few large jars, thereby keeping the dependency graph small but making it harder to upgrade small parts and providing the feeling a lot of unnecessaary things are loaded into memory One solution is to provide a tool which packages only used classes and their dependencies into one or a few custom jars. Unfortunately, the dependency tracking mechanism needs some metadata to track dependencies created by data driven class loading. A possiblity to get around this would be a tool which notifies classes used during compilation and JUnit test runs and creates a customized jar from the pool of library and program classes in the deployment stage. J.Pietschmann --------------------------------------------------------------------- To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: commons-dev-help@jakarta.apache.org