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