On Tue, 27 Jun 2000, Conor MacNeill wrote: > David, > > A while ago I submitted a patch to handle the dependencies between java > files. This patch included code which can read in a class file and analyse > its contents. There is no need to worry about classpaths or to use > introspection. All you need is the file (just the bytes actually).
This is what a custom classloader would do. Fetch the class as bytes and define a Class. Introspection would follow. The custom classloader could handle the classpath issue. > It should > be able to tell you whether a class implements a given interface. This code > was originally part of a larger library I wrote to read and manipulate class > files. (Perhaps a case of intersourcing :-) > > You will find the code by mailing [EMAIL PROTECTED] That approach is probrably best suited for the javac task since the dependencies are far more complex that just timestamp checking. For rmic I think that it is sufficient to just check the timestamp of the class file as the only dependency for the Stub/Skel file is the class being compiled. > > Now that would be one approach to selecting which classes need to be > rmic'ed. Perhaps it is a little heavyweight. A caveat - the code in that > message is not currently part of the ant CVS tree. I agree. It is a little heavyweight for Rmic > > As to the general issue of classpath management, I have tended to create a > separate, internal Java task to run a helper class. I can run that class > with an appropriate classpath. I do not like to have to run ant with a > classpath which includes the project ant is building. I think others have > considered custom class loaders but I have not really thought that out yet. > > Let me know what you think. I was going to suggest a custom classloader at the project level where several classpaths may be added and would only be seen by this project. I am not sure whether this can be done cleanly or whether the classpaths added would need to be explicitly removed. That way things could be self-contained and be independent of the shell scripts. This is an added bonus for nightly builds. > > Conor > > > -----Original Message----- > > From: David Maclean [mailto:[EMAIL PROTECTED] > > Sent: Tuesday, 27 June 2000 0:09 > > > > I did think about using MatchingTask to pick out classes to process. There > > is a slight complication in that Rmic works on classes and to determine > > whether a class needs to be rmic'd, a check for an implements > > java.rmi.Remote. This can be done by introspection. I was not quite sure > > of the best way to handle it. When doing a match on a directory I think > > that it should be the directory of the classes, but I do not think that > > the directory of the classes will be in the classpath. I was having a > > similar problem on another project with the build classes not being in the > > classpath unless explicitly added to the shell script/batch file. It is > > rather messy when writing a task that operates on classes. Another thing > > is that Rmic complains if given a class that does not implement > > java.rmi.Remote > > > > >
