[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [wtp-incubator-dev] Extensibility of XSLT editor menus, popups, etc.
|
I think you guys should work on getting this component building as a separate distro. People can play around with it and give feedback. When everyone is happy about stability and the way it integrates with the rest of WTP we can start talking about graduating from incubation. Also, have you passed all the IP reviews for your code contribution and the dependencies? Only incubating projects qualify for parallel IP, so all reviews have to be completed before graduation.
- Konstantin
Sent from my mobile messenger.
-----Original Message-----
From: David Carver [mailto:d_a_carver@xxxxxxxxx]
Sent: Friday, December 21, 2007 06:40 AM Pacific Standard Time
To: WTP Incubator Dev list
Subject: Re: [wtp-incubator-dev] Extensibility of XSLT editor menus, popups, etc.
DOUG SATCHWELL wrote:
> I really dislike all the menu contribution mechanisms we have in
> Eclipse at the moment. I find it really confusing - so any improvement
> on that basis would be a good thing!
>
> The only reservation I have about utilising the proposed extension
> point is that the XSLT plugins would then depend on it. That means
> that we couldn't get the XSLT code to pass the review process before
> the new extension point code has passed the review process, and I
> really want to get something accepted soon.
I think we need to get hooked into the WTP milestone process, so that we
can better organize and corrodinate what needs to be done and by when.
Honestly, as the original X-Assist and organevolt XSLT editors currently
stand I would put them in a M1 category, with several key features
missing from a UI aspect.
I do think getting the XSLT Launcher in as a M1 is fine. Could be the
validators, but the area I think we really need some good spit and
polish and useability is in the specific features for the XSLT Editor
itself. At the momement from a development standpoint, it provides
only the bare minimum of features needed from an XSLT stand point.
So I think we need to really do some planning, have some clear goals
laid out and when we want to get them done.
We also need to make sure that we are following all of the committer
guidelines where possible:
http://wiki.eclipse.org/Development_Conventions_and_Guidelines
There is also the issue of getting the nightly builds in place.
http://wiki.eclipse.org/WTP_Build_Process_and_Procedures
Unit Tests developed for existing functionality.
http://wiki.eclipse.org/WTP_Compatibility_Tests
http://wiki.eclipse.org/WTP_Functional_Test
David is there a documented process for the Eclipse Milestone process.
I believe Eclipse follows a modified OpenRUP process. Is there a link
that lays this out.
While I agree we need to get some code out, I think we are still a ways
away from integrating as a whole into the main stream code.
So I think we need to shoot for a Milestone 1, so that we can get it out
there for the community to kick around, and start reporting bugs against
it. Also, are there any outstanding bugs in the sourceforge databases,
that we should migrate over to the incubator? If so, we should address
those as well as we go forward.
I come from working with an agile methodology that is a combination of
Scrum and XP, so I'm a firm believer of maintain a product backlog, and
iterative development.
>
> However, as soon as the extension point code is (or is likely to
> be) accepted then I have no problem to converting our plugins to use
> it. Do you agree?
I agree, and many of the features where we need to contribute can't be
done until bug 212330 is looked at and implemented, which last comment I
received from Amy Wu she wasn't going to have time to review it until
after M4 was out the door. Which means not until January time frame.
Dave
_______________________________________________
wtp-incubator-dev mailing list
wtp-incubator-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/wtp-incubator-dev
Notice: This email message, together with any attachments, may contain information of BEA Systems, Inc., its subsidiaries and affiliated entities, that may be confidential, proprietary, copyrighted and/or legally privileged, and is intended solely for the use of the individual or entity named in this message. If you are not the intended recipient, and have received this message in error, please immediately return this by email and then delete it.