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
