Re: easy way to see fixed/resolved issues

[Mark Brouwer <ma...@marbro.org>]

Hi Holger,

Holger Hoffstätte wrote:
> Mark,
> 
> Mark Brouwer wrote:
>> Mark Brouwer wrote:
>>
>>> So I think you are right, I will reopen this issue for someone else to
>>> resolve it. Do want to have a go at it Gregg ;-) ?
>>
>> As nobody volunteered for RIVER-230 I'm removing it from the issues to
>> solve for AR2. It still would be nice if somebody would tackle this one
>> given statements as "This is a big pain, especially for new Jini users"
>> ;-P as it would solve 2 problems, getting currently non-committers
>> involved and solving the pain. I have still plenty of stuff to do for
>> AR2 so I'm not volunteering here.
> 
> I just had a look (not knowing anything about ClassDep until now ;) and 
> commented on the bug. I understand the output problem (reproduced 
> easily) and sanitizing the input seems easy enough too, so if that's all 
> then I can take care of this.

Great, I tried to assign you to this task but apparently I can't select
you as you are not a committer for River, so I'll just make a remark you
are working on it. With regard to your 2 sub-problems as mentioned in
the comment of RIVER-203 I'm not sure whether you are thinking of
changing the behavior of the output of ClassDep as is (when using the
-files option), I don't have a clear view of how people expect it to
behave but it seems that a platform specific output is what you want.

So I would only fix #1, something else you might consider is the path
separator used for the classpath (; versus :) as that one is currently
tied to the OS as well.
-- 
Mark

ClassDep platform dependencies (was Re: easy way to see fixed/resolved issues)

[Holger Hoffstätte <ho...@wizards.de>]

(this is about RIVER-203)

Mark Brouwer wrote:
> are working on it. With regard to your 2 sub-problems as mentioned in
> the comment of RIVER-203 I'm not sure whether you are thinking of
> changing the behavior of the output of ClassDep as is (when using the
> -files option), I don't have a clear view of how people expect it to
> behave but it seems that a platform specific output is what you want.

That was my questoin - it is not clear to me how and where the output is 
consumed (probably ant/jar). In any case, it is only a single isolated 
change so we can do whatever we want - either a unified /-style regardless 
of platform or platform-native. As far as I can see the output does not 
include absolute path information like e.g. drive letters, which ruin 
everything anyway..

> So I would only fix #1, something else you might consider is the path
> separator used for the classpath (; versus :) as that one is currently
> tied to the OS as well.

That one is a JVM flag (-cp) and already accepts both / and \ but as you 
said has different separators. It seems to me that fixing this would 
require at least a new custom classpath flag and a custom classloader.

Holger