blob: f4cbe4f68b1b4f85d40cc6ac86e836954f084ee8 [file] [log] [blame]
jst server development meeting notes
This file, while dated 20041014 actually covers a number of meeting
over the last several weeks.
20040819 Meeting notes
Task: (?) someone should try doing "local build" following
Naci's instructions, make sure it works ok, and give feedback
on directions
Task: (Gorkem) add unit tests (even if just a few simple onces
that show class can be instantiated (and therefore plugin
Task: (?) need to incorporate Elipse base "performance unit
tests framework" to have regular performance data
20040916 Meeting notes
Jim des Rivieres presented "how to make platform quality code
101". (that can have a long life, etc).
his presentation under miscdocuments directory, WTP Server Core APIs.ppt.
He emphasized difference between API and SPI ... which is not
well deliniated in current code.
Later, referred to these web references.
Some other API-related resources:
Jim continued his presentation.
For server core apis, it would seem more "SPI" would be
extension points (and their required interfaces).
When asked about what type of documentation is good examples
of what we should produce, Jim mentioned two levels.
First, they type of overview, such as that which exists in the
Eclipse platforms Developers Guide
Second, java doc: especially recommended core.resources and
relationship to team.
also mentioned jdt.core as good example of java doc.
Task: (?) "developers guide" writeup for server provider and
server clients
Jim asked about JSR's 88 and 77. Its' believed 77 is already
in JSK 1.4?
No one knew enough to know implications (if they were things
we should re-use, or things we had to be compliant with).
Naci aggreed to study JSR 77 more
Task: (Naci) JSR 77 -- what its it, what's implications for
Task: (?) JSR 88 -- what is it and what's implications for us?
Task?: (?) JMX was mentioned too (but I didn't get what was
Naci mentioned something about difference between 'deploy' and
'publish' though I didn't get what it was (here in my notes),
Probably because I was rememering how this has been confusing
in the past with customers who think we provide a formal
system (managing version dependancies, groups of uesrs, etc.)
for large IT shops.
Short meeting, We had connection trouble, so Naci and Gorkem
could not present as planned.
Marshall Culpepper from joined call (on Dallas
Task (Marshall Culpepper) provide a JBoss adapter similar to
how we have provided tomcat adapters.
Tim mentioned lots of conversations with Darin Wright on
improving launch support, so, for example, can have other
launch preferences,
a launched page history,
I opened feature request to "hold"
this area of work, though
we will need to be more specific with what we want/need.
short meeting, Naci and Gorkem couldn't join.
It was announced, though, that Arthur is having a face-face
meeting in Toronto with Tim De Boer, Jim des Rivieres, and
others from Toronto, in order to make faster progress in
designs and making "platform quality apis".
Gorkem and Naci gave some demo's of "Lomboz-like" generic
server support.
they had 3 .server files for jboss, jonas, and something else
I don't recall.
The immediate feedback in the meeting was
1) why couldn't the XML files be "moved" to the
extension point model and be part of a plugin?
2) even if that was undesirable for some cases/needs,
there needs to be an "import" function that reads
the file from one place on disk (or internet!?) and
places them in metadirectory?, instead of user having
manually copying a file to the right place.
Arthur wondered if this framework was generic enough to be
used for a data base server (apache derby) to "publish" stored
procedure calls.
Naci responded that currently there was actually some J2EE
specific stuff in there now, but in general could be made
more generic.
Naci had some UML diagrams he started to present before we ran
out of time.
[Naci perhaps you could please put those in miscdocuments,
so we can read/study before next meeting].
It quickly became apparent that we could not talk about
'server tools' design too much further, without addressing
the 'flexible project' design, so everyone wanted to start
focusing on that in weeks to come.
After the call, in chat with Jim we decided before we jump
right into project support, that we come up with and agree on
some use-cases that have been implicit in this discussions. That
way we can assign priorities to implementing/testing the use
cases. This is critical so that we maintain focus and maintain the
right scope of the design and the API. We discussed how it
would be desireable to have the use-cases ironed out before the 10/25
"focused design meeting".
Task: (david) create initial rough draft of use cases