I missed last months call (totally miss
the window for the homework ;-)) and can't make it today, but I would like
to make a few comments in the spirit of trying to get some threads going
in the mailing list.
I think the path of blockitecture that
shows functional areas of a project and the inner and interdependencies
on other blocks is the top level to start with. Perhaps the blocks are
like super features., and can be drilled into to see plug-in cross dependancies.
This is where we started last year, and how we structured the TPTP pages,
but we did not get consistency across projects. This can define technical
I think Wenfeng's idea bring this structure
to the human level, and writing some functional use cases that span projects
is a good thing, although hard at times. I believe each project should
commit to some viewlets/flash walk throughs of their project functional
area. Most are doing this. On top of that there are some walk throughs
that can span projects without show all the intricate details of each.
I know that doing a TPTP centric demo that crosses WTP, JDT, TPTP and BIRT
positioning goes over very well with users and developers alike. I am creating
a viewlet that does this now, and would encourage other leads to try the
same intentional effort, if for no reason but to force awareness of cross
project collaboration potential.
In the past the only way I have seen
successful cross big project demo/architectures etc. is when a single person
is given the job to deliver it. I am not sure we have such a person in
this case so the best efforts of many seem to have to do ;-)
Bjorn Freeman-Benson <bjorn.freeman-benson@xxxxxxxxxxx> Sent by: eclipse.org-architecture-council-bounces@xxxxxxxxxxx
11/08/2005 01:11 AM
Please respond to
November 7th Conference call agenda
Monthly Architecture Council Conference Call
Second Tuesday of each month, 8am PST, 11am EST
the call time/date in Q1? A number of people cannot make the second Tuesday
of each month calls, so shall we try a different day and/or time in Q1?
what we want to have in the Architecture Council section of the Roadmap.
We need to collectively decide what we want to show for our time this year
- what sort of documentation of the current architecture are we (which
mostly means you all) willing to spend time writing for the end of the
year? The answer might be (disappointingly) "very little", but
now is the time to step up to the task or to state definitely that we won't
be doing much.
Last month we decided "We discussed what we should
be creating for the architecture diagram for the Roadmap. Is it a summary
of the current state? Is it a discussion of the future and forward looking
architecture? Is it useful to the existing projects or is it just seen
as a waste of time providing no benefit to the teams? We concluded that
we needed to have documentation of the existing architecture before we
could do anything more forward looking so we resolved (ok, ok, Bjorn browbeat
everyone into agreeing) to spend a half-hour writing up their current view
of the Eclipse Platform architecture. These emails might provoke
discussion on our mailing list, plus Bjorn is going to merge these all
into a discussion document for our next call."
Using our decision
for (2) we will review our inputs from the last meeting and decide what
we can do next to produce the Roadmap. The inputs from the last meeting
were very varied:
David Williams: documents and diagrams showing the dependencies
between WTP subsystems
Richard Gronback: list of subsystems across Eclipse
John Graham: traditional boxes view of subsystems seen
Bjorn Freeman-Benson: list of subsystems across Eclipse
Kevin Haaland: list of sub-projects and plug-ins and key
components in the Platform
Wenfeng Li: list of subsystems across Eclipse grouped
by scenarios: tools, designer, deployment
Kai Nyman: agreed with Wenfeng about using use-case scenario-based
Tim Wagner: no input
Michael Scharf: no input
Finally, we will
talk about agenda items for the Council meetings.
The Lattix folks have offered to come to the Council meetings
and show us what they have been extracting of the Eclipse architecture
using their tools.
eclipse.org-architecture-council mailing list