>From: "Craig McClanahan" <[EMAIL PROTECTED]> > > 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? >
I like option 3. I don't think I can add much value in terms of the best maven config. The maven builds make it very simple to checkout the source and build. I think the process of building from the source adds to the examples. > 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 :-). > +1 > Craig Gary
