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
> >
> >
