| 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?) | |