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