ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Conor MacNeill" <co...@m64.com>
Subject RE: Platform independend classpath in build.xml?
Date Wed, 31 May 2000 14:37:46 GMT
Stefan,

> -----Original Message-----
> From: Stefan Bodewig [mailto:bodewig@bost.de]
> Sent: Wednesday, 31 May 2000 23:11
> To: ant-dev@jakarta.apache.org
> Subject: Re: Platform independend classpath in build.xml?
>
>
> >>>>> "JG" == Jean-Noel Gadreau <jngadreau@activcard.com> writes:
>
>  JG> Moreover, I think the same problem will arise for other path
>  JG> (like for .DLL or .so needed by some JNI classes for
>  JG> instance). How about defining a task that is able to add path to
>  JG> a list in a crossplatform way, which would not be limited just to
>  JG> CLASSPATH. This way, if you need to specify PATH (to find a tool
>  JG> or something), we could use the same class.
>
> Please let's not reinvent the wheel. Thomas Haas has built what you're
> describing and has sent it as part of our JUnit task.
>

I think many people have not seen this code. This is probably because it not
yet integrated into CVS and most people did not realise that it has more
than just a JUnit task. I remember the path discussion only vaguely as I was
pretty busy at the time.

Anyway I fetched the JUnit post from 20th April (I think it is the latest)
and had a quick look at the Path element code. I have a few problems with
the code (not the concept) as it currently stands. I'd like to discuss those
now so you and Thomas can consider them when this stuff is to be committed.

The PathElement object seems strange to me. It seems to be not so much a
real object, as a set of methods to manipulate the surrounding Path object.
One effect is that the Path object is not composed of PathElement objects,
which I found odd. Another effect is that repeated calls to setLocation on a
PathElement will add multiple File objects to the outer Path object.
Similarly the setPath method adds multiple entries to the Path object, which
again I found a strange thing for a PathElement object.

If the current structure is to be retained, I think the class and its
methods should be renamed.

PathElement -> PathManipulator
setLocation -> addLocation
setPath -> addPath.

I think it would be better, however, to just drop the PathElement object and
have these methods on the Path object itself.

Hope you and Thomas don't mind getting these comments. I'm planning to have
a closer look at the JUnit stuff soon and would like to give some feedback
on that too.


> Thomas is on vacation AFAIK but I hope he will get back to this
> soon. Thomas is a commiter so he can make these changes quicker than I
> could put together the necessary patch.
>

I think all the committers are on holidays at the moment :-)
OK, its not true, I know they are pretty busy right now.

Cheers
Conor


Mime
View raw message