I think you are way off base here. The problem this error is reporting is
serious, and that is why we are displaying it so prominently. I have only
seen one instance where the message is a red-herring, and that is the case
where your entire workspace is a Subversion WC. In that scenario, you can
get rid of the error message by storing your projects outside the
workspace and importing them in.
We have a String point to a file, and that is it. To do anything with it
in Eclipse we need an IResource. Eclipse provides a method that lets us
get an IResource based on the string. When the call to that method comes
back null, we display this errorm, but only once per session as you will
typically get it for every file. This null causes Subclipse to not be
able to function correctly.
We had lots and lots and lots of users getting this problem before we
figured it out and the symptoms were very hard to interpret. The fix is
generally easy to resolve.
I have no plans to remove the error message. I already added code to make
sure it only displays one time per Eclipse session.
Mark
Rob Oxspring <roxspring@imapmail.org> wrote on 03/31/2006 06:53:44 AM:
> I've seen the path-case error message cropping up in eclipse and have
> pretty much learned to ignore it as there is no discernible problem
> caused. FWIW my workspace path matches the canonical path and the same
> holds for the files created within - and eclipse seems happy whether the
> workspace path matches or not anyway. IMHO the message is annoying,
> confusing and infuriating so here are some suggestions to improve it:
>
> Shorten the message. The error message is long winded and by the end
> appears to offer hypotheses of why it may or may not be the case. This
> information is great for a FAQ but just detracts from the point of the
> original error. Keep the error message concise and meaningful.
>
> Display both expected and actual values. At present one version of the
> value is displayed and it is unclear whether this is the one eclipse is
> expecting or the one causing the problem. From the sounds of it you
> should be able to get the before and after since its just about the
> inputs / outputs to the javahl layer. Displaying both will make the the
> error message less ambiguous.
>
> Allow the warning to be disabled. Unless you are certain that there
> will be a problem ultimately caused by this mismatch then the message
> will simply be displayed daily and slowly ignored subclipse's error
> messages altogether. Stop the rot and allow people to disable the
> message so that they really do see important errors in the future.
>
> Offer some advice. Maybe the advice is complicated enough that it
> should go in the FAQ but please offer something. At the moment there
> seems to be nothing that I can do to reproduce the effect of issue 285
> so I'm left with no clues as to what I have to do to stop the warning
> from appearing and I'm offered no real reasons to do so either, other
> than the daily indecipherable error message from subclipse.
>
> I'm trying not to be too grumpy here guys, subclipse is generally really
> good and I appreciate the effort but this message just leaves me baffled
> and frustrated every time I pay attention to it.
_____________________________________________________________________________
Scanned for SoftLanding Systems, Inc. and SoftLanding Europe Plc by IBM Email Security Management Services powered by MessageLabs.
_____________________________________________________________________________
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Fri Mar 31 15:34:57 2006