Skip to main content
Jump to: navigation, search

WTP Architecture Working Group

Revision as of 21:20, 22 October 2007 by (Talk | contribs) (Next meeting)

WTP Architecture Working Group


  • 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/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.


  • 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

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


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: core & ui split docs - Tim 2: note to community - Nitin 3: dependencies, build - Konstantin, Tim 4: note to broader community, users

- API - - need new policy - grandfather date - deprecation policy: API, internal, provisional - legitimate v.s non-legitimate usage

Action item: Tim to write up a policy for review

Next meeting

Date: Monday, October 29th
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:

Back to the top