Difference between revisions of "WTP Architecture Working Group Archive"

From Eclipsepedia

Jump to: navigation, search
m (New page: == 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 buil...)
 
m (Minutes 9/14)
 
Line 35: Line 35:
 
*Konstantin: Check on legal issues and send out source to tool
 
*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
 
*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
 +
 +
[[Image:Wtp-arch-wst.gif]]
 +
[[Image:Wtp-arch-jst.gif]]

Latest revision as of 12:56, 5 November 2007

Contents

[edit] 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

[edit] Minutes 9/24

Attendees: Nitin, Tim dB

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

[edit] Meeting 10/1

Attendees: Konstantin, Nitin, Cameron, Tim

  • minutes lost, thanks to a Windows blue screen

[edit] Meeting 10/9

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

Topics: API, best practises

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