[wtp-dev] WTP Cross-Project Requirements

[David M Williams <david_williams@xxxxxxxxxx>]

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
VE project. 

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
those too). 

If anyone knows of any other areas I've
forgotten about, 
please let me know. (but otherwise,
vote early, vote often :)

David

= = = = =

Common Command (stack) framework
https://bugs.eclipse.org/bugs/show_bug.cgi?id=37716
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
function, causing 
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
with/between components 
such as EMF, GEF, and VE (they all have
their own "common" 
command(stack) framework). 
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
https://bugs.eclipse.org/bugs/show_bug.cgi?id=73695
Frankly, we in WTP need to better understand
limitations here
and provide specific use cases. (We're
probably a month or two 
away from having that complete detail).


Content-type-based editor look-up
https://bugs.eclipse.org/bugs/show_bug.cgi?id=37668
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
update site
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75764
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 
fixes/improvements? 

JEM should be feature available from
update site
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75761
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
feature, available 
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
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75762
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
the moment.  
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
tool, 
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
4.0
https://bugs.eclipse.org/bugs/show_bug.cgi?id=75763
As Unicode 4.0 is the most recent character
spec, 
and as Eclipse is intended to be general
purpose platform, 
it needs to be compliant. This is important
since
there is a certain "ripple effect"
on other spec's and 
standards. For example, to be fully
support 
XML 1.1 requires compliance with Unicode
4.0.