Re: [wtp-incubator-dev] Extensibility of XSLT editor menus, popups, etc

["Konstantin Komissarchik" <kosta@xxxxxxx>]

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.