Stefan, > -----Original Message----- > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > Sent: Wednesday, 31 May 2000 23:11 > To: [EMAIL PROTECTED] > Subject: Re: Platform independend classpath in build.xml? > > > >>>>> "JG" == Jean-Noel Gadreau <[EMAIL PROTECTED]> 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
