Sean, I think an example app using this stack would be a good showcase.
+1 Gary >From: "Sean Schofield" <[EMAIL PROTECTED]> > > Craig, > > I've been working on my own little sample app that integrates shale > with several facelets, tomahawk, spring and hibernate. I was just > about to ask on this list if anybody would be interested in working on > it with me if I contributed it here. > > It sounds like our ideas for a sample app are overlapping a little. I > don't know anything about the new JPA and I'm not too "itchy" to learn > it at the moment. Right now I'm trying to further my understanding of > hibernate which is in much higher demand from my clients right now. > > What is the Spring support like for JPA? Can we plug it into their > DAO pattern? If so we could provide two different ORM solutions which > would be kind of cool. > > Anyways, my plan for this was to build a petstore type app that would > be a little fancier then our traditional mail reader. I wanted to use > some tomahawk components and have several admin tools. Maybe its too > ambitious for a sample app but I think it would be good to demonstrate > how these technologies can all work together. I've achieved some nice > results with one or two but increasingly I am finding that I would > like to use all of them (shale, spring, jsf and hibernate) in my apps. > > So I can continue to work on this offline as my own personal > experiment or we could try to work something out here. Let me know > what you think? I'm short on opensource time for the next month or so > but all of my spare time is going towards this effort right now. > > Sean > > On 7/17/06, Craig McClanahan wrote: > > As part of finishing up a Shale example app that uses Java Persistence > > Architecture (JPA) ... a refinement of the "mailreader" example that I > > ported to Shale and JPA for JavaOne but needed to be cleaned up before > > being > > published ... I'm planning on creating a couple of new things in our source > > repository: > > > > * A new examle app (shale-apps/shale-mailreader-jpa) that implements > > the MailReader functionality, but uses JPA entity classes. No real > > issues here, with respect to the repository structure. > > > > * A "sandbox" area, with an initial Maven project that creates the > > entity classes for the USERS and SUBSCRIPTIONS tables themselves, > > plus the JPA persistence unit that defines them. This should be > > something different than a typical Shale example, because none of > > these classes have any direct dependence on Shale ... they are more > > along the lines of the mailreader-dao project that is part of the Struts > > sandbox, but doesn't have any direct dependence on Struts. > > > > Before doing so, it's probably worth spending some time figuring out how we > > want the source repository to be organized -- which, in turn, is directly > > affected by our thoughts on what (if any) artifacts we would plan on > > releasing separately. So, let's talk about that question first, and then > > figure out how it might affect the overall organization. Here's what I have > > thought about so far (with references to where things *currently* live, not > > where they might end up): > > > > (1) The Shale master POM (maven/master-pom). This needs to be > > separately releasable because it actually needs to be released before > > a Shale release can be done that depends on it. > > > > (2) The other Shale "parent" POMs (top level, shale-apps, shale-dist, > > and the proposed sandbox). IIUC, these only need to be separately > > releaseable if we ever want to separately release something that > > depends on them. For example, a decision to allow ourselves to > > release the example apps independently of the framework would > > require that we release the shale-apps POM separately as well. > > > > (3) The individual Shale-based example apps. I've seen many projects > > go through the decision process about whether to actually release > > such things separately, and most of them (so far) have opted not to > > do all the extra work. I'm leaning that way as well ... the corner > > case > > for me is if you want to ship a *new* example app, but I suppose that > > people interested in the samples would be willing to use snapshot or > > nightly build versions (at least until we released an x.y.z update to > > the > > framework :-). > > > > (4) The individual pieces of the framework. Although we have these > > segregated for reasonable technical reasons (primarily having to do > > with the dependencies that get imposed on end users), I can't really > > see us trying to do releases of these things separately. But it would > > be technically feasible to do so, if we thought it wise. > > > > What do you think? > > > > Once we have decided what we think we might actually want to release > > separately, we can have Wendy guide us into the best overall organization > > of > > the source repository :-). > > > > Craig > > > >
