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