To expand upon my earlier idea ... petstore src/main/java <-- domain objects and service interfaces go here petstore/petstore-1 <-- specific technology combos petstore/petstore-2
So you have a petstore.jar artifact produced in the top level module and petstore-1.war and petstore-2.war in the lower levels. You are reusing the domain and service interfaces across all of the different combo apps. But if one combo uses facelets and another uses clay, we don't really want a whole separate war. Maybe we could have a switch in the maven build where you select your view technology? That might be kind of cool. I'm working on a project with Matt Raible (creator of appfuse) right now so maybe he has some ideas on how to cut down on duplication. Stylesheets and images are another area where we don't want to duplicate things. Sean On 7/19/06, James Mitchell <[EMAIL PROTECTED]> wrote:
Rather than creating alternate versions and duplicating work, couldn't we just showcase a few pages or a piece of the app to demo clay? -- James Mitchell On Jul 19, 2006, at 11:03 AM, Sean Schofield wrote: > Yes and you probably noticed that I didn't mention Clay. I'm not > really up on that piece of the Shale toolbox but we would definitely > want a version of the "petstore" that used Clay and one that used > facelets. > > Sean > > On 7/19/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: >> 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 >> > > >> > > >>
