I agree -- it seems that the eclipse team have got some challenges on
hand.. they maybe need a greater range of test beds than they have
available.. bugs seem to get called fixed when they are only fixed for one
platform -- that seems to indicate that some of the eclipse programming is
not platform independent.
While the code may run on all platforms the
file structures
(permissions/ownership/
system specific file organization
browser interfaces
make me wonder whether the design incorporates the need for a simple
configuration process OR if it does the information on how to configure is
not readily accessible for configuration immediately upon extraction
without some substantial prior experience of how eclipse works.
For eample I did not realize the help system was browser dependent until,
quite by chance, I found a link from the interface. It is clear the
internal browser has problems.
My impression is we have a series of chicken and egg problems here... you
need to find a solution to the help file issue without having access to
the help files which might provide a clue on how the help file system
works!!~!
Frankly designing the help file in a way that is dependent upon randomly
created ports is not, to my mind, a very good idea in any case. It
conflicts with basic security requirements for network based control of
port access and apparent dependency upon some apparently specific browser
behaviors creates other difficulties.
Could these these difficulties be symptomatic of a windows development
environment?
Does eclipse need an installation checking routine that analyses the
application file structure, cecks that all files are in place with
appropriate runtime access and gives a report on what is working and what
is not working giving clues on how to fix it?
In my case some progress has been made -- see the thread on welcome and
help - With the upgrade to 3.1RC1-1 I now have the welcome working but not
the help!!