Jump to: navigation, search

Difference between revisions of "WTP Architecture Working Group"

(Next meeting)
m (March 31st meeting)
 
(9 intermediate revisions by 2 users not shown)
Line 1: Line 1:
 
= WTP Architecture Working Group =
 
= WTP Architecture Working Group =
 
[[Category:Eclipse Web Tools Platform Project]]
 
[[Category:Eclipse Web Tools Platform Project]]
 +
[[Category:Eclipse Web Tools Platform Architecture]]
  
 
=== Plans ===
 
=== Plans ===
Line 13: Line 14:
 
* Work with project leads for the "bottoms up" perspective, and address what's realistic
 
* Work with project leads for the "bottoms up" perspective, and address what's realistic
  
Meeting archive: http://wiki.eclipse.org/WTP_Architecture_Working_Group_Archive
+
Meeting archive: [[WTP Architecture Working Group Archive]]
  
Start of a new wiki page: http://wiki.eclipse.org/WTP_Projects_and_Features
+
Start of a new wiki page: [[WTP Projects and Features]]
  
 +
Start of a new wiki category: [http://wiki.eclipse.org/index.php?title=Category:Eclipse_Web_Tools_Platform_Architecture Eclipse Web Tools Platform Architecture]
  
 
== October 22nd ==
 
== October 22nd ==
 +
Cameron, Konstantin, Nitin, Tim
  
 
=== Features ===
 
=== Features ===
:* Core & UI shouldn't be split without specific reason, other feature splits (docs?) may not make as much sense either
+
:* 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
 
:* 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
 
:* interest is in starting with some of the core components - creating better features and separate downloads to promote reuse
Line 29: Line 32:
 
Action items:
 
Action items:
 
:* 1 - Write up policy on feature design for review (Tim)
 
:* 1 - Write up policy on feature design for review (Tim)
:* 2 - Send note to community to get feedback on facets & snippets split, other ideas (Nitin)
+
:* 2 - Gather feedback on facets & snippets split, other ideas (Nitin)
 
:* 3 - Investigate dependencies and build changes required to make the split (Konstantin, Tim)
 
:* 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)
 
:* 4 - Send note to broader community (projects & users) to increase awareness and get feedback (later)
Line 43: Line 46:
 
:* Write up a new policy for review (Tim)
 
:* Write up a new policy for review (Tim)
  
== Oct 29th & Nov 5th meeting ==
+
== 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: http://wiki.eclipse.org/WTP_API_Policy
+
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 ==
 
== Next meeting ==
::Date: Monday, December 10th
+
::Date: Monday, March 31st
 
::Time: 2pm EDT/11am PDT
 
::Time: 2pm EDT/11am PDT
 
::Call-in Info: 1 866-245-5059 Passcode: 4203514
 
::Call-in Info: 1 866-245-5059 Passcode: 4203514
  
:Review feevack on proposed architecture policy
+
* Internal API usage
:Update deprecation and internal usage policy
+
:Update on action items
+

Latest revision as of 13:45, 31 March 2008

WTP Architecture Working Group

Plans

  • 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