ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Maclean <da...@cm.co.za>
Subject RE: Rmic patch
Date Mon, 26 Jun 2000 15:03:42 GMT

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 ant-dev-get.1301@jakarta.apache.org.

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:david@cm.co.za]
> > 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
> >
> >
> 


Mime
View raw message