Rmic patch

[David Maclean <da...@cm.co.za>]

Hi there

I sent a patch of tbe Rmic taskdef to this list on Friday and I was
wondering as to whether someone has had a look at the patch yet. Comments
are most welcome.

Cheers
David

Re: Rmic patch

[Stefan Bodewig <bo...@bost.de>]

>>>>> "DM" == David Maclean <da...@cm.co.za> writes:

 DM> On 26 Jun 2000, Stefan Bodewig wrote:

 >> As to the part where you check whether rmic needs to be run at
 >> all: I decided to keep this to the people with more knowledge.

 DM> This works like the Javac task by looking at the .class file's
 DM> timestamp and comparing it to the _Stub.class and/or _Skel.class

Yes, I've understood that much 8^). I'm just not sure whether this
check is sufficient - as much as the simple comparison of modification
times in javac is sufficient in most cases but not in general.

Stefan

Re: Rmic patch

[David Maclean <da...@cm.co.za>]

On 26 Jun 2000, Stefan Bodewig wrote:

> Hi David,
> 
> thank you for the patch. Even though nobody's taken the time to
> comment on it yet, I'm sure it has been noticed by several people.
> 
> I'm not that familiar with rmic so I didn't look too close, sorry.
> 
> The first part of your patch enables the rmic task to work on several
> files. I'd suggest to use a different approach here, let Rmic extend
> MatchingTask and you should be done with a few adjustments. What do
> you think?
> 
> As to the part where you check whether rmic needs to be run at all: I
> decided to keep this to the people with more knowledge.

This works like the Javac task by looking at the .class file's timestamp
and comparing it to the _Stub.class and/or _Skel.class

> 
> Stefan
> 

Re: Rmic patch

[Stefan Bodewig <bo...@bost.de>]

Hi David,

thank you for the patch. Even though nobody's taken the time to
comment on it yet, I'm sure it has been noticed by several people.

I'm not that familiar with rmic so I didn't look too close, sorry.

The first part of your patch enables the rmic task to work on several
files. I'd suggest to use a different approach here, let Rmic extend
MatchingTask and you should be done with a few adjustments. What do
you think?

As to the part where you check whether rmic needs to be run at all: I
decided to keep this to the people with more knowledge.

Stefan

Re: Rmic patch

[Mark Brouwer <ma...@virgil.nl>]

Hi All,

First I must admit I didn't follow this thread completely, second I have
no time to see whether I'm getting totally of topic :-) but what I do
know is I build a long time ago a build tool capable of delivering end
products based on our companies naming conventions. Part of that build
tool was automatic RMI stub/skeleton end EJB generation (for WebLogic
only).

In the future I would like to migrate to ant but currently I have no
time for that. However I thought lets drop in my knowledge of automatic
RMI generation. As far as I know it is conform the RMI specs and also
takes EJB's into account (by skipping them). I attach it over here.

In short it takes a file with paths to java files. The program assumes
correlating classes can be found through its classloader, the classes
will be checked to see if they are RMI objects, if so they are written
to a files and can be used as input for the RMI compiler. However I
think the isRMIObject method is the one to have a look at. This one is
dependent on the javax.ejb extension for it checks whether the object is
an EJB.

Regards,
-- 
Mark Brouwer
Virgil B.V.

RE: Rmic patch

[David Maclean <da...@cm.co.za>]

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
> >
> >
> 

RE: Rmic patch

[Conor MacNeill <co...@m64.com>]

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). 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.

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.

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.

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
>
>

RE: Rmic patch

[David Maclean <da...@cm.co.za>]

On Mon, 26 Jun 2000, Conor MacNeill wrote:

> David,
> 
> I had a very quick look at it. My initial reaction was that you might like
> to consider reworking it as a MatchingTask which is the standard way that
> ant handles processing multiple files. Now that Stefan has committed the
> includesfile patch, you would be able to use the file approach as well.
> 
> It is however, not so simple since rmic deals with classnames and
> MatchingTask deals with files. It is possible to convert between the two and
> has been considered in the past. Below is an excerpt from that discussion.
> 
> What do you think?

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

> 
> Conor
> 
> 
> > -----Original Message-----
> > From: Kuiper, Arnout [mailto:Arnout.Kuiper@nl.origin-it.com]
> > Sent: Tuesday, 2 May 2000 1:36
> > To: 'ant-dev@jakarta.apache.org'
> > Subject: RE: Ant question - iterative processing
> >
> >
> > > From: Mykins, Ann [mailto:Ann.Mykins@medic.com]
> > > This seems awfully repetitive - is there a nice way of using
> > > a directory
> > > tree and pattern to basically do an rmic on anything that ends in
> > > "Impl.java"?
> >
> > Not yet, but in the next version of Ant, the rmic task should be
> > harmonized with all the other file-related tasks, such that it
> > can use the include/exclude patterns.
> >
> > It's on my todo...
> >
> >   Arnout
> >
> 
> --
> Conor MacNeill
> Home: conor@m64.com
> Work: conor@cortexebusiness.com.au
> Web:  www.cortexebusiness.com.au
> 
> 
> > -----Original Message-----
> > From: David Maclean [mailto:david@cm.co.za]
> > Sent: Monday, 26 June 2000 22:33
> > To: ant-dev@jakarta.apache.org
> > Subject: Rmic patch
> >
> >
> > Hi there
> >
> > I sent a patch of tbe Rmic taskdef to this list on Friday and I was
> > wondering as to whether someone has had a look at the patch yet. Comments
> > are most welcome.
> >
> > Cheers
> > David
> >
> >
> 

RE: Rmic patch

[Conor MacNeill <co...@m64.com>]

David,

I had a very quick look at it. My initial reaction was that you might like
to consider reworking it as a MatchingTask which is the standard way that
ant handles processing multiple files. Now that Stefan has committed the
includesfile patch, you would be able to use the file approach as well.

It is however, not so simple since rmic deals with classnames and
MatchingTask deals with files. It is possible to convert between the two and
has been considered in the past. Below is an excerpt from that discussion.

What do you think?

Conor


> -----Original Message-----
> From: Kuiper, Arnout [mailto:Arnout.Kuiper@nl.origin-it.com]
> Sent: Tuesday, 2 May 2000 1:36
> To: 'ant-dev@jakarta.apache.org'
> Subject: RE: Ant question - iterative processing
>
>
> > From: Mykins, Ann [mailto:Ann.Mykins@medic.com]
> > This seems awfully repetitive - is there a nice way of using
> > a directory
> > tree and pattern to basically do an rmic on anything that ends in
> > "Impl.java"?
>
> Not yet, but in the next version of Ant, the rmic task should be
> harmonized with all the other file-related tasks, such that it
> can use the include/exclude patterns.
>
> It's on my todo...
>
>   Arnout
>

--
Conor MacNeill
Home: conor@m64.com
Work: conor@cortexebusiness.com.au
Web:  www.cortexebusiness.com.au


> -----Original Message-----
> From: David Maclean [mailto:david@cm.co.za]
> Sent: Monday, 26 June 2000 22:33
> To: ant-dev@jakarta.apache.org
> Subject: Rmic patch
>
>
> Hi there
>
> I sent a patch of tbe Rmic taskdef to this list on Friday and I was
> wondering as to whether someone has had a look at the patch yet. Comments
> are most welcome.
>
> Cheers
> David
>
>