Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 28721 invoked from network); 17 Jul 2002 17:18:52 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 17 Jul 2002 17:18:52 -0000 Received: (qmail 27160 invoked by uid 97); 17 Jul 2002 17:19:07 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 27122 invoked by uid 97); 17 Jul 2002 17:19:04 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 27108 invoked by uid 98); 17 Jul 2002 17:19:03 -0000 X-Antivirus: nagoya (v4198 created Apr 24 2002) X-Authentication-Warning: costinm.sfo.covalent.net: costin owned process doing -bs Date: Wed, 17 Jul 2002 10:17:15 -0700 (PDT) From: costinm@covalent.net X-X-Sender: costin@costinm.sfo.covalent.net To: Ant Developers List Subject: Re: Splitting up optional.jar In-Reply-To: <04fb01c22db2$5fa458f0$1219570f@ranier> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 Wed, 17 Jul 2002, Steve Loughran wrote: > 1. I understand why you are breaking it up by dependency, but IMO it should > be broken up by functionality, and each jar can have its own dependencies > (or not) That's a good argument... In my opinion ant-junit is just the ant 'adapter' for junit.jar ( which is an external and well defined package ). Since won't work without junit.jar, I think it would be much better if the task would be included in junit.jar in the first place ( and maintained by junit people ). Same for bsf, etc. I think 'by functionality' organisation should be used for most 'standalone' or 'generic' tasks ( like ant-xml ), but 'by dependency' should be used for all tasks that are very specific to a particular package. ant-weblogic should have all tasks that are specific to weblogic, while ant-jspc would be a good place for jsp-related tasks ( and that may have a soft dependency on jasper, weblogic, resin, etc ). > 2. we need ant version numbers in the jar titles, of course, to stop version > confusion. The risk is we introduce a new bugrep "I am running ant1.7 but > the task doesnt support the option authmode="liberty""; the cause > being they have the ant1.6 version of this (hypothetical) task on the cpath. +1 And eventually have independent release cycle for 'task packages' - most of those can work very well in ant1.5, and it would be very valuable for users to get updates and fixes for the current version instead of waiting for 1.6 to get the whole thing. > 3. we need a manifest to handle versions and dependencies; it could be > the normal manifest, or it is our own XML descriptor. +1 With a very strong -1 on using (only ) a XML descriptor for things that are well-defined for the normal manifest - it is important that generic tools are able to manipulate the jar. So I think all dependency, version, etc should go to MANIFEST. The task=classname should go in a properties file ( and I think we should settle on a default location and name - like META-INF/ant.properties ). Everything else should go to the XML descriptor ( like docs, etc ). It would be fine if all the information are put in the XML descriptor as long as the packaging process will generate MANIFEST and ant.properties from the XML. Costin -- To unsubscribe, e-mail: For additional commands, e-mail: