WTP Architecture Working Group

WTP Architecture Working Group

Plans

• Update our high level architecture document

• Make current with how things currently are (add, JSF, JPA, DTP, etc.)
• Make current with how we want things to be (improved componentization, etc)
• Make a Projects View
• Make a Features View

• Make recommendations that are important to release 3.0, such as

• Can we install and/or enable proper capabilities for various install scenarios?
• Should/can some plugins move to better components/features?

• Work with project leads for the "bottoms up" perspective, and address what's realistic

Meeting archive: WTP Architecture Working Group Archive

Start of a new wiki page: WTP Projects and Features

Start of a new wiki category: Eclipse Web Tools Platform Architecture

October 22nd

Cameron, Konstantin, Nitin, Tim

Features

• Core & UI shouldn't be split into separate features without specific reason, other feature splits (docs?) may not make as much sense either (splitting them between plug-ins is good)
• We're not going to redo all of WTP, but we should have an overall architectural plan
• interest is in starting with some of the core components - creating better features and separate downloads to promote reuse
• discussed of the chicken & egg problem with separating out features and having adopters
• decided that facets & snippets are the most logical components for reuse

Action items:

• 1 - Write up policy on feature design for review (Tim)
• 2 - Gather feedback on facets & snippets split, other ideas (Nitin)
• 3 - Investigate dependencies and build changes required to make the split (Konstantin, Tim)
• 4 - Send note to broader community (projects & users) to increase awareness and get feedback (later)

Internal API Usage

• Reviewed current policy of usage scans, why it was adopted, and the need for a new policy
• Suggestion of a grandfather date whereby we no longer accept usage scans
• Discussed how our deprecation policy (for API, internal, and provisional) is tightly tied to this
• Discussed the need to separate between legitimate v.s non-legitimate usage
• Need some form of component/project 'graduation' from internal usage policy

Action item:

• Write up a new policy for review (Tim)

Oct 29th, Nov 5th, Nov 12th, Nov 19th meetings

Cameron, Konstantin, Nitin, Tim

Reviewed action items and spent most of the time discussing our API policy: WTP API Policy

Dec 10th meeting

Cameron, Konstantin, Nitin, Tim

Followed up on action items

• Nitin sent email to wtp-dev and eclipse.webtools newsgroup about "expanded downloads", comments to be gathered around WTP Expanded Downloads
• Konstantin managed to get the PDE build system working for WTP and will explore alterations after the holidays

Agreed that with members on vacation and shutdown of the shortened M4 in the following week, to adjourn until January.

March 31st meeting

Cameron, Nitin, Tim

We've been asked to make an addendum/recommendation to the API policy for 'internal' dependencies within WTP - e.g. when is it ok to use x-friends or use internal code from another plugin or project.

Notes:

• 'component' boundary is our projects/sub-projects at a minimum. Project lead may decide to use subcomponents or features.
• within a component, use of x-friends is allowed. all other internal packages should be marked as such.
• once x-friends is in use, other plugins in the same component can use internal API.
• teams should use bugzilla for API requests across project/component.
• we currently have no good way to track internal usage across projects/components. hopefully api tools will help here in the future.

Next meeting

Date: Monday, March 31st

Time: 2pm EDT/11am PDT

Call-in Info: 1 866-245-5059 Passcode: 4203514

• Internal API usage