Your comment about building an import checker reminds me of something I've been wanting. During development, I have a big source tree directory, the top of which is "com", and the whole thing roughly maps to the package hirerarchy. Often is the time that I want to take some app out of that big huge tree and jar it up, and lately, since jdk1.2 I've wanted to use executable jar's to pass tool apps around and make them easy for me to double click them alive from the desktop. The class files that comprise any one of these tools is a small subset of the total source tree. Problem is how do I jar up the minimal set of classes such that the executable jar is self-sufficient. How do I find all the classes I need? This is where I wanted some utility that took an app's main class file and pulled together all required class files, and I thought it would probably require chasing stuff down via import statements. I did do something in lieu of developing such a utility just to play with the executable jars. I can run the app right out of the tree using C-c C-v C-r so I went to a shell buffer and invoked the app using -verbose. This deposited in the shell buffer a list of all the classes loaded into the vm. Since I don't need the library classes, ie., java.*, etc., I had to snarf up the list and put it into a file and grep out the user classes. Voila, I had my set of classes. (Although I know that if there is any delayed dynamic loading of classes, ie., class.forName(...), my hacky process would not obtain such classes. ) Nonetheless I now had the set of classes that needed to go into the jar. To make the jar I used a macro to massage the load statements into "jar -uf ..." statements and so on. I mention this because I'm curious if your notion of an import checker comprehends this, and to check if this functionality is interesting to others. For all I know there's another, better way to do this. Bottom line is that I'd love to have a tool in which I simply pointed it at appMain.java and out popped an executable jar. Phillip Lord wrote: > >>>>> "Larry" == Larry Riedel <[EMAIL PROTECTED]> writes: > > > Larry> I thought the idea of making a function similar to > Larry> "jde-help-class", which "for an unqualified class name, > Larry> [tests] for existence of the class in each package imported > Larry> into the current source file", such that "if the class exists > Larry> in more than one package, it lets you choose which one you > Larry> really want." > > Larry> I thought it made sense that "the same functionality could be > Larry> extended to jumping to the source file that defines the > Larry> class." > > Actually this is an interesting point. The jump to source > code which I wrote, based on a hack from the jde-help code, does > mostly this, which was very easy because all of the functionality was > there already. It was just a question of tying the different bits > together. However in this case the fully qualified class name is > resolved on the basis of what classes are loaded into the beanshell > JVM, wheras it would make a whole lot more sense to use the > information in the import statements. I guess if these failed then it > could fall back on JVM loaded classes. > > Having a quick look through jde-complete, Ive noticed that > there is some parsing of import statements done in there, so some of > the work has already been done. > > I think that I might have a go at implementing this sometime. > Most of the functions would be useful for something that I have wanted > to write for a long time which is an "import checker" which tests > whether a class has all of its required imports, and perhaps more > importantly that all of the imports declared in a class are actually > necessary... > > Phil
begin:vcard n:Johns;Rich x-mozilla-html:TRUE org:Trajecta version:2.1 email;internet:[EMAIL PROTECTED] title:Software Designer note:[EMAIL PROTECTED] x-mozilla-cpt:;0 fn:Rich Johns end:vcard
