Return-Path: Delivered-To: apmail-jakarta-ant-user-archive@apache.org Received: (qmail 55142 invoked from network); 22 Sep 2002 21:00:11 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 22 Sep 2002 21:00:11 -0000 Received: (qmail 14950 invoked by uid 97); 22 Sep 2002 21:00:46 -0000 Delivered-To: qmlist-jakarta-archive-ant-user@jakarta.apache.org Received: (qmail 14917 invoked by uid 97); 22 Sep 2002 21:00:45 -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 14901 invoked by uid 98); 22 Sep 2002 21:00:44 -0000 X-Antivirus: nagoya (v4218 created Aug 14 2002) X-Sent: 22 Sep 2002 21:00:03 GMT Message-ID: <3D8E2F59.5070503@ehatchersolutions.com> Date: Sun, 22 Sep 2002 17:00:09 -0400 From: Erik Hatcher User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Ant Users List Subject: Re: regexp file content search to form a fileset References: <5.0.2.1.0.20020921214742.02323660@mail.weblaces.com> <5.0.2.1.0.20020922085654.02b3e4f0@mail.weblaces.com> 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 Elizabeth Cooper wrote: > I have already considered that I would need to write my own Selector, > but that if there was any other practical way, it would be more > favorable to my management-types. Again, seems like a reasonable workaround for the near future, but a custom selector should be no more than a couple of lines of code to accomplish what you're after. > We use information in the "header" area of the file to group JavaBean > classes into jars when we build our products. It is not for > documentation purposes, but instead for distribution purposes. Dispell the myth that X"doc"let has anything whatsoever to do with "documentation". Its about using class/method/variable metadata to generate or do whatever you want. It might not be all that appropriate in your situation as you're just trying to group files by category, but I'd recommend using a more general @tag to do this than a home-made "# Java-Bean:..." syntax. You will get more long-term mileage out of codifying metadata with @tags since you'll be able to process those in a more standard manner than having a custom selector, for example. For your particular use-case (or user story?! :) I would recommend categorizing by directory structure rather than using categories in source code to do this. Place all files that belong in one JAR in one directory tree, and likewise for the other categories. Unless I'm missing something about what you're doing, that is. Doing tricky patternset/fileset stuff and using that to selectively build JAR files from one tree of code is something I aggressively avoid. > into categories for jarring. The traditional way is to mark these > comments in the top section of the file where the @author, etc. stuff > is. For example, there is a separate "# comment-whatever" if the class > goes into the base jar, or into one of several specialized jar. Also, it > is common to mark a file as "not-released", so it does not go into any > jars. To process this with Ant, we currently use an exec with grep and > find to make a list of qualifying files, then use this filelist for > javac. I can still do this, but it would be so much nicer with a regexp > Selector. Should be trivial enough to accomplish - much easier to develop than what it took to develop your current solution I'd bet. > Does this make sense -- I do not know much about XDoclet, and I do not > think I need to use @tags -type marking for my purpose -- what do you think? XDoclet is probably not appropriate your case, but I do recommend you use a more standard metadata notation than "# Java-Bean:...". See JSR 175 - @tags are the way Sun plans on supporting metadata. XDoclet is already there to handle it, and many more tools will in the future as well. FYI, XDoclet's JavaBean support currently generates BeanInfo classes and I18N resource properties files. So not quite what you're after. But a custom template could generate the categorized file lists. Erik -- To unsubscribe, e-mail: For additional commands, e-mail: