On 7/18/06, Sean Schofield <[EMAIL PROTECTED]> wrote:
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.
I think you'd likely get takers ... and I'd like to help. 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.
The mechanism we have for publishing examples is pretty scalable ... each example stands on its own and doesn't affect the size of the framework download. Therefore, I don't think its necessarily a bad thing for examples to have overlapping sets of functionality, because they will likely focus on different combinations of features to show off together. Therefore, I don't think there would be any reason not to want the app you described above. 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.
JPA is supported ... at least by Spring 2. However, if you aren't using Spring for anything else it's a lot of extra conceptual overhead to *require* it ... JPA + JSF handle all the basic stuff already (dependency injection, transactions, etc.). 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.
Sounds like this might really be a series of sample apps that share a common persistence tier -- and that would be a good thing. We definitely can use examples that go beyond the "hello, world" level of some potential ways to integrate these technologies together. 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.
I'd love to see something like this in Shale (presuming you're using Shale as part of the infrastructure, of course :-). Thinking a bit further, we might want to also toy with the idea of an examples catalog that concisely documents the technologies featured in each example, plus a consistent format for the website associated with each sample that discusses the design patterns employed, highlights interesting implementation points, and mentions alternative approaches. Sean Craig On 7/17/06, Craig McClanahan <[EMAIL PROTECTED]> 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 > >
