Jump to: navigation, search

Difference between revisions of "WTP Architecture Working Group"

m (Next meeting)
m (Minutes 9/14)
Line 12: Line 12:
 
* 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 ==
 
  
Attendees: Konstantin, Nitin, Cameron, David W, Tim dB
 
 
Some of the discussion topics:
 
 
* Long term, should/can we use the build to enforce architecture?
 
:* 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.
 
 
* Should the foundation supply build infrastructure?
 
:* They already provide machines and much infrastructure.
 
:* Build project has been suggested before, and other teams have tried to promote their build technology. There has been little interest.
 
:* Maybe just common scripts or mechanisms for sharing?
 
 
* WTP structure is now several projects, each with core vs UI and wst vs jst split.
 
:* 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.
 
::* Is that overkill?
 
::* Unclear how 3.4 provisioning work might affect features.
 
:* We should break components up as wst/jst when we look at dependencies.
 
:* Will want to eventually investigate core/UI split too.
 
 
* Should tests be included as part of a component?
 
:* 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.
 
:* 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.
 
 
* Discussed Konstantin's visualization tool, Tim's dependency tool
 
:* Cyclic dependencies are bad. :)
 
 
* What about other dependencies, esp. JDT?
 
:* Should come up with a view of what requires JDT and what doesn't.
 
:* JEM and EMF both have non-JDT/JDT split as well.
 
 
Actions:
 
 
*Konstantin: Check on legal issues and send out source to tool
 
*Tim: Start modifying tool to read K's component format, start editing existing wiki page, setup next meeting
 
  
 
= Minutes 9/24 =
 
= Minutes 9/24 =

Revision as of 11:53, 5 November 2007

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


Minutes 9/24

Attendees: Nitin, Tim dB

- canceled since nobody else showed up!
  • review last minutes
  • finish discussion
  • action items
  • where to go?

Meeting 10/1

Attendees: Konstantin, Nitin, Cameron, Tim

  • minutes lost, thanks to a Windows blue screen

Meeting 10/9

Date: Tuesday, October 9th
Time: 2pm EDT/11am PDT

Attendees:


Topics: API, best practises

Wtp-arch-wst.gif Wtp-arch-jst.gif

October 22nd

Features

  • Core & UI shouldn't be split without specific reason, other feature splits (docs?) may not make as much sense either
  • 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 - Send note to community to get 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 meeting

Reviewed action items and spend most of the time discussing our API policy:

http://wiki.eclipse.org/WTP_API_Policy


Next meeting

Date: Monday, November 5th
Time: 2pm EDT/11am PDT
Call-in Info: 1 866-245-5059 Passcode: 4203514
Review feature architecture policy
Review deprecation and internal usage policy
Update on action items


Start of a new wiki page: http://wiki.eclipse.org/WTP_Projects_and_Features