|Craig McClanahan||Jul 16, 2006 10:04 pm|
|Gary VanMatre||Jul 17, 2006 7:23 pm|
|Wendy Smoak||Jul 17, 2006 8:11 pm|
|Craig McClanahan||Jul 17, 2006 9:19 pm|
|James Mitchell||Jul 18, 2006 6:22 am|
|Greg Reddin||Jul 18, 2006 11:02 am|
|Sean Schofield||Jul 18, 2006 2:20 pm|
|Sean Schofield||Jul 18, 2006 2:52 pm|
|Craig McClanahan||Jul 18, 2006 4:46 pm|
|Craig McClanahan||Jul 18, 2006 4:53 pm|
|Sean Schofield||Jul 18, 2006 5:30 pm|
|Wendy Smoak||Jul 18, 2006 5:39 pm|
|Gary VanMatre||Jul 19, 2006 7:09 am|
|Sean Schofield||Jul 19, 2006 8:03 am|
|James Mitchell||Jul 19, 2006 9:25 am|
|Sean Schofield||Jul 19, 2006 10:36 am|
|Gary VanMatre||Jul 19, 2006 10:58 am|
|James Mitchell||Jul 19, 2006 11:13 am|
|Craig McClanahan||Jul 19, 2006 1:42 pm|
|Sean Schofield||Jul 19, 2006 1:54 pm|
|Craig McClanahan||Jul 19, 2006 2:15 pm|
|Greg Reddin||Jul 19, 2006 2:34 pm|
|Sean Schofield||Jul 19, 2006 3:41 pm|
|Wendy Smoak||Jul 19, 2006 9:37 pm|
|Greg Reddin||Jul 20, 2006 9:44 am|
|Wendy Smoak||Jul 20, 2006 12:48 pm|
|Greg Reddin||Jul 20, 2006 1:23 pm|
|Wendy Smoak||Jul 20, 2006 2:02 pm|
|Greg Reddin||Jul 20, 2006 4:32 pm|
|Wendy Smoak||Jul 20, 2006 10:49 pm|
|James Mitchell||Jul 23, 2006 11:01 am|
|Greg Reddin||Jul 23, 2006 2:36 pm|
|Craig McClanahan||Jul 23, 2006 5:02 pm|
|James Mitchell||Jul 25, 2006 7:07 am|
|Craig McClanahan||Jul 25, 2006 9:24 am|
|James Mitchell||Jul 27, 2006 9:41 pm|
|Craig McClanahan||Jul 28, 2006 8:20 pm|
|Sean Schofield||Jul 29, 2006 6:17 am|
|Wendy Smoak||Jul 29, 2006 6:59 am|
|Sean Schofield||Jul 29, 2006 9:48 am|
|Craig McClanahan||Jul 29, 2006 10:18 am|
|Craig McClanahan||Jul 29, 2006 10:23 am|
|Sean Schofield||Jul 29, 2006 5:30 pm|
|Craig McClanahan||Jul 29, 2006 9:32 pm|
|Greg Reddin||Jul 30, 2006 4:46 pm|
|Subject:||Re: Source Repository Organization and Release Strategy Thoughts|
|From:||Craig McClanahan (crai...@apache.org)|
|Date:||Jul 19, 2006 2:15:11 pm|
On 7/19/06, Sean Schofield <sean...@gmail.com> wrote:
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?
Lets assume you have set up a JPA persistence unit with its associated entity classes for a particular database ... this is the sort of thing that would go at the top level of your proposed directory structure (with the webapps that use it in subdirectories). Now, assume you have a different persistence unit for a different database, and now you need to write a sample app that uses both libraries. Which top level directory do you put the webapp underneath?
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.
As long as a sample app used only one service interface, that idea works. I'm just trying to think ahead a little.
Note that a hierarchical directory structure isn't really important to the build process ... dependencies are declared by identifiers, not by relative location, no matter how they are organized.
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.
We might want a separate grouping (parallel to shale-apps) for them. But the key thing is that they *don't* themselves depend on Shale, so they shouldn't IMHO just be intermixed with Shale artifacts, or Shale-dependent sample 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.
Go for it! We have zero facelets based apps at the moment :-).