Return-Path: Mailing-List: contact dev-help@ant.apache.org; run by ezmlm Delivered-To: mailing list dev@ant.apache.org Received: (qmail 3501 invoked from network); 13 Mar 2003 16:07:23 -0000 Received: from junior.lgc.com (134.132.72.99) by daedalus.apache.org with SMTP; 13 Mar 2003 16:07:23 -0000 Received: from lgchvw01.lgc.com (lgchvw01.lgc.com [134.132.93.107]) by junior.lgc.com (8.11.6/8.11.3) with SMTP id h2DG6Jj04179 for ; Thu, 13 Mar 2003 10:06:19 -0600 (CST) Received: from 134.132.93.152 by lgchvw01.lgc.com (InterScan E-Mail VirusWall NT); Thu, 13 Mar 2003 10:07:24 -0600 Received: by lgchexchbh.ad.lgc.com with Internet Mail Service (5.5.2653.19) id <1C7PKWCN>; Thu, 13 Mar 2003 10:07:24 -0600 Message-ID: From: Dominique Devienne To: "'Ant Developers List'" Subject: RE: Possible TaskDef donation Date: Thu, 13 Mar 2003 10:07:23 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Why not posting it? Seems interesting enough, and once it's posted people can start using it or tweaking it. Best way to post it is to open a new Enhancement in Ant's BugZilla. This keeps everything in one place (posted sources, JARs, ZIPs, whatever and the discussions about it). Using URLClassLoader works fine, but does require having the dependent classes available. Maybe somehow Ant's can be leveraged to not require the dependencies. --DD -----Original Message----- From: Berin Loritsch [mailto:bloritsch@apache.org] Sent: Thursday, March 13, 2003 9:57 AM To: dev@ant.apache.org Subject: Re: Possible TaskDef donation Dominique Devienne wrote: > This is indeed interesting. I do something quite similar for another purpose > (scans a JAR for all classes having a give static method signature, executes > all these methods, gathering the meta-info required, generate a XML file > then stuck into the JAR's META-INF directory). > > Something I do is to restrict scanning classes to only those that match a > given patternset to speed things up (you often know which part of your > package tree to look things, or could use a naming convention to find things > faster). This makes the scanning quite a bit faster (we have big JARs). > > All this to say that you specific use case if very useful, but the more > generic action all scanning the classes of a JAR and doing something that > ultimately updated the JAR somehow would be even more useful. Allowing to > plug over 'actions' rather than the default 'looking for services' would be > very very useful IMHO. Easy change to make--I can make it a protected action (the actual check). > What are your dependencies? BCEL? Do you load the actual classes (so need > dependent classes on the classpath)? Standard JVM. I use JarFile to read the JAR contents, and JarOutputStream to write the new JAR. I construct a new URLClassLoader that uses the current classloader as the parent, and loads the input JAR in as well. I then scan the contents of the JAR only looking at the ".class" entries. I load the class, and perform my checks on the class itself. > Thanks for sharing this with us. --DD > > PS: BTW, I don't think you can edit the JAR in place... Would be nice though. I guess we could make it something where you can use a directory instead of the JAR. It would alter the scanning code though. Do you want me to post what I have?