This makes sense, but doesn't scale to cases where a particular demo uses more than one service library of some sort. I'd suggest we put the things like domain object libraries either at the same level as apps, or in the sandbox (since they typically will not have any Shale dependencies).
What do you more then one service library? My thinking was that the service interfaces only would be shared with the child applications. All child applications would do the exact same thing but with variations on the technology. Ex. JPA instead of Hibernate.
The latter is what I'm planning to do with the MailReader entity classes ... a jar project named "mailreader-jpa" in the sandbox (created locally on my system, but not checked in yet).
I'm thinking that we start out in the sandbox for everything related to this "petstore". Long term I don't see the advantage of having the domain objects in the sandbox but the apps in shale-apps.
If "choose your view technology" means choosing between JSP/Clay/Facelets but always using JSF components, this would be a matter of tweaking config files and swapping out some of the resources. But I worry that the machinery to make this happen would be complex enough and fragile enough to hide the simplicity we're trying to show off.
Yeah you're right. Its probably better to just document the slight variation.
My thinking is we want examples that have "one each" of the technology choices that someone would have to make, and perhaps have part of the docs talk about "if we had chosen xyz instead, we would have done this instead of that." By the way, there is a very nice full featured demo of Clay already (shale-clay-usecases).
Ok so nobody will mind if I use facelets? We get a lot of questions about facelets on this list and the myfaces list.
Craig
Sean
