20041021 Agenda | |
Assess where we are in design process and progress. | |
Team agreed to flush out some use cases to help focus design, | |
and help "limit" Release 1 API to only the most important, known paths. | |
Jim expressed concern about having two API's, one for "known J2EE servers" and | |
one for "unknown servers" (if I'm capturing it correctly) ... and how | |
we do not want two API's. (then its not really an API, too difficult to maintain, | |
and evolve). | |
Discuss task to create explicit use cases | |
Jim and Tim will create/add some while meeting in Toronto, and | |
Jim will discuss next meeting (Tim will be not be able to make next meeting). | |
Naci and Chuck will create some for project layout and discuss | |
next week. | |
How to capture the "intersection" of servers tools and projects is still | |
unclear (to me). | |
The role of ant tasks? | |
Are they a positive thing? | |
Or an admission we simple don't know what to do? | |
(so instead of writing java code, users can write ant scripts?) | |
team clarified: | |
partially is to handle fact that while war's and ear's are "spec'd" where | |
they go on a server is not. | |
Also, many users have pre-existing build scripts they want to continue to use. | |
Some of generic server support is providing launch parameters | |
Naci acknowledge some of what's there now, | |
could be moved to "properties files"/preference pages | |
Project layout -- only briefly discussed -- Naci and Chuck to clarify next week. | |
Eclipse native layout | |
maps to J2EE runtime spec | |
runs in place via file system | |
Maven project layout. | |
Native layout with linked contents | |
maps to J2EE runtime spec (via links) | |
runs in place (after following links?) | |
Can we infer/derive links, given some constaints | |
or user hints? | |
User layout with user specified contents/relationships | |
What do *we* do, then? (what's value add?) | |