Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "WTP Architecture Working Group"

m (Next meeting)
m (March 31st meeting)
 
(30 intermediate revisions by 3 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 Architecture]]
  
 
=== Plans ===
 
=== Plans ===
Line 12: 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
  
== Minutes 9/14 ==
+
Meeting archive: [[WTP Architecture Working Group Archive]]
  
Attendees: Konstantin, Nitin, Cameron, David W, Tim dB
+
Start of a new wiki page: [[WTP Projects and Features]]
  
Some of the discussion topics:
+
Start of a new wiki category: [http://wiki.eclipse.org/index.php?title=Category:Eclipse_Web_Tools_Platform_Architecture Eclipse Web Tools Platform Architecture]
  
* Long term, should/can we use the build to enforce architecture?
+
== October 22nd ==
:* We can build things separately, but build currently assumes things go in a single order, i.e. once things are built they are available to all future components that build.
+
Cameron, Konstantin, Nitin, Tim
  
* Should the foundation supply build infrastructure?
+
=== Features ===
:* They already provide machines and much infrastructure.
+
:* 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)
:* Build project has been suggested before, and other teams have tried to promote their build technology. There has been little interest.
+
:* We're not going to redo all of WTP, but we should have an overall architectural plan
:* Maybe just common scripts or mechanisms for sharing?
+
:* 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
  
* WTP structure is now several projects, each with core vs UI and wst vs jst split.
+
Action items:
:* Suggestion of packaging individual features or components for download. Could be on a separate download page, but would allow adopters to get exactly what they want.
+
:* 1 - Write up policy on feature design for review (Tim)
::* Is that overkill?
+
:* 2 - Gather feedback on facets & snippets split, other ideas (Nitin)
::* Unclear how 3.4 provisioning work might affect features.
+
:* 3 - Investigate dependencies and build changes required to make the split (Konstantin, Tim)
:* We should break components up as wst/jst when we look at dependencies.
+
:* 4 - Send note to broader community (projects & users) to increase awareness and get feedback (later)
:* Will want to eventually investigate core/UI split too.
+
  
* Should tests be included as part of a component?
+
=== Internal API Usage ===
:* In practice we should have component level tests (part of a component) and project/cross-component tests. In reality most tests are component level, but some components have cross-component tests too.
+
:* Reviewed current policy of usage scans, why it was adopted, and the need for a new policy
:* General agreement we should look at our dependencies without tests (to investigate the clean/runtime view of things) and also compare to see what dependencies tests add.
+
:* 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
  
* Discussed Konstantin's visualization tool, Tim's dependency tool
+
Action item:
:* Cyclic dependencies are bad. :)
+
:* Write up a new policy for review (Tim)
  
* What about other dependencies, esp. JDT?
+
== Oct 29th, Nov 5th, Nov 12th, Nov 19th meetings ==
:* Should come up with a view of what requires JDT and what doesn't.
+
Cameron, Konstantin, Nitin, Tim
:* JEM and EMF both have non-JDT/JDT split as well.
+
  
Actions:
+
Reviewed action items and spent most of the time discussing our API policy: [[WTP API Policy]]
  
*Konstantin: Check on legal issues and send out source to tool
+
== Dec 10th meeting ==
*Tim: Start modifying tool to read K's component format, start editing existing wiki page, setup next meeting
+
Cameron, Konstantin, Nitin, Tim
  
= Minutes 9/24 =
+
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
  
Attendees: Nitin, Tim dB
+
Agreed that with members on vacation and shutdown of the shortened M4 in the following week, to adjourn until January.
- canceled since nobody else showed up!
+
  
* review last minutes
+
== March 31st meeting ==
* finish discussion
+
Cameron, Nitin, Tim
* action items
+
* where to go?
+
  
= Meeting 10/1 =
+
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.
  
Attendees: Konstantin, Nitin, Cameron, Tim
+
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.
  
::minutes lost, thanks to a Windows blue screen
+
== Next meeting ==
 
+
::Date: Monday, March 31st
= Meeting 10/9 =
+
::Time: 2pm EDT/11am PDT
::Date: Tuesday, October 9th
+
::Time: 2pm EDT/11am PDT
+
 
+
Attendees:
+
 
+
 
+
Topics: API, best practises
+
 
+
 
+
= Next meeting =
+
::Date: Tuesday, October 16th
+
::Time: 2pm EDT/11am PDT  
+
 
::Call-in Info: 1 866-245-5059 Passcode: 4203514
 
::Call-in Info: 1 866-245-5059 Passcode: 4203514
(will meet on following Mondays for several weeks)
 
 
  
Start of a new wiki page: http://wiki.eclipse.org/WTP_Projects_and_Features
+
* Internal API usage

Latest revision as of 14: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

Back to the top