[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-incubator-dev] Extensibility of XSLT editor menus, popups,
|
DOUG SATCHWELL wrote:
I'm happy for you to take on this part of the work. It is important to
get a plan together, and to keep the rest of the world up to date via
the wiki. The planning itself needs to be a consultation process. It
needs to be realistic too - I'm sure we all have full-time jobs so we
need to keep the size of the tasks manageable.
+1
OK - lets work on a milestone plan that we can use. I do want this to
result in the XSL code getting published to an update site early on -
the earlier we get it there the sooner we can work on ironing out the
bugs. I'll explain why I think we can do this.
I think that there are 2 streams of development here as per the
proposal at
http://www.eclipse.org/webtools/incubator/proposals/XSLTools_proposal.html.
1) XSL launching + debugging.
2) XSL editing capabilities and validation.
The intersection between is what goes into 'core': XSL Schema catalog
entries and the contentType extension.
Don't forget the XPath view and the customized XML outline view.
Stream 1 is actually quite mature because it has been based on
existing mature code that has been converted. My aim is to get this up
to scratch within the next 2 weeks - that means documentation, JUnit
tests and integration with the WTP build process. This is the spit and
polish.
Stream 2 is much less mature - we need a great deal more than spit and
polish here, so milestones for this are distant.
There's been a lot of restructuring in this, but it's coming along bit
by bit, I just haven't committed anything yet.
The point is that the 2 streams are more or less independent. You can
deliver one without the other, as long as the plugins are suitably
arranged. And the sooner we deliver something - even if it is just
stream 1 - then the better for us because we get to know how the
process works and get people using and testing it for us. As
Konstantin points out, it looks like we should be getting it built as
a separate distro first.
So what I would like to propose is that in the first part of the plan
we make a determined effort to get stream 1 to production quality and
released. Then we turn our attention to stream 2.
Or we could work in parallel - as these proposed streams are pretty
much independent.
In other words, we can get stream 1 to RC1, while stream 2 is still
at M1.
Is that sensible?
Er, I'm a little wary of re-using milestone labels such as M1 and RC1
which will easily confused with the Ganymede plan items.
I'd suggest referring to the Ganymede milestone plan (+3 stage) as a
timebox and then focus the effort accordingly in a tabular fashion:
Feature: XLST Launching
M4: Main functionality done
M5: Tested and packaged (update site)
M6 [API freeze] End user help
M7: Cheat sheet, etc.
...
Feature: XPath view
M4: As imported from Orangevolt XLST + namespace support
M5: Enhancement xxx, yyy, zzz, Bug aaa
M6 [API Freeze] Tested and packaged (update site)
M7: End user help
...
Feature: Validator
M4: Use existing X-Assist features in existing validation framework
M5: Move to new validation framework
...
The features could then be evaluated and tested independently.
Well, that's my take on this, but ultimately, I'm not religious in these
matters.
-Jesper
