The following is a list of "cross
project" requirements I'm aware of from my
discussions with various WTP teams.
Mostly they are requirements on
the base Eclipse platform, but one against
It is not intended to be a list of every
defect, but just major
areas that are nontrivial effort and/or
date and/or packaging
sensitive. The purpose of this list
is assist "Eclipse Foundation 3.1" planning.
(Though, if anyone knows of any long-range
(i.e. 4.0) requirements, don't
hesitate to open feature requests for
If anyone knows of any other areas I've
please let me know. (but otherwise,
vote early, vote often :)
= = = = =
Common Command (stack) framework
This is an old bugzilla ... oft requested,
but no action taken.
The work around is for unrelated components
to pre-req some
common component which provides this
awkward dependancies among components
not otherwise related
except for a desire to provide good
Undo experience for user.
One challenge now, though, is to do
this in a
way that does not break API compatibility
such as EMF, GEF, and VE (they all have
their own "common"
In WTP, not having this common command
stack at the platform level
causes, for example, some plugins to
pre-req an EMF
plugin, so, by convention, all can do
the same thing. This is not
as modular as our users/clients require.
Improved flexible project support
Frankly, we in WTP need to better understand
and provide specific use cases. (We're
probably a month or two
away from having that complete detail).
Content-type-based editor look-up
In addition to a UI for content-based
editor look-up (and UI for many
contentType based preferences), there's
probably a number of extension
points that need "updating"
to use content-type as well as file extensions
in their "specs".
WebDav should be feature available from
The importance of this is that many
"web developers" will want to use
webdav but there's no easy solution
to packaging or people to improve it
(that I'm aware of) so, my thought is,
if it was easily to add to dev. env.
perhaps users from community would come
forward with more
JEM should be feature available from
Since our project needs to pre-req JEM
(but not all of VE)
and since our version of JEM needs to
coexist (obviously) with the
version in VE (since many users would
have both installed),
it would be best to package JEM as a
from the eclipse update site, so it
would both be easy for users to stay
current, and for there to be no risk
conflict if users updated VE or WTP.
Improved Run/Debug Integration/ExtensionPoints
In discussions with WTP members, two
specifics have been mentioned
to provide a more "integrated experience"
for Eclipse/WTP users.
1). Some "run/debug on server"
options should be made available (via
extension point) on normal "launch"
dialog (and preferences).
To just add pages is probably not scalable,
but we (I should say "I"
don't have any better suggestions at
2. Similarly, "run/debug on server"
needs some "recent history"
memory, so, for example, if a user "run's"
from navigator a specific JSP
file, then later re-run's from the previously-known-as-running-man
the most recently ran page should be
remembered and understood to be
the intended 'run' option (not just
relaunch the server).
Support for/Compliance with Unicode
As Unicode 4.0 is the most recent character
and as Eclipse is intended to be general
it needs to be compliant. This is important
there is a certain "ripple effect"
on other spec's and
standards. For example, to be fully
XML 1.1 requires compliance with Unicode