|Craig McClanahan||Jul 16, 2006 10:04 pm|
|Gary VanMatre||Jul 17, 2006 7:23 pm|
|Wendy Smoak||Jul 17, 2006 8:11 pm|
|Craig McClanahan||Jul 17, 2006 9:19 pm|
|James Mitchell||Jul 18, 2006 6:22 am|
|Greg Reddin||Jul 18, 2006 11:02 am|
|Sean Schofield||Jul 18, 2006 2:20 pm|
|Sean Schofield||Jul 18, 2006 2:52 pm|
|Craig McClanahan||Jul 18, 2006 4:46 pm|
|Craig McClanahan||Jul 18, 2006 4:53 pm|
|Sean Schofield||Jul 18, 2006 5:30 pm|
|Wendy Smoak||Jul 18, 2006 5:39 pm|
|Gary VanMatre||Jul 19, 2006 7:09 am|
|Sean Schofield||Jul 19, 2006 8:03 am|
|James Mitchell||Jul 19, 2006 9:25 am|
|Sean Schofield||Jul 19, 2006 10:36 am|
|Gary VanMatre||Jul 19, 2006 10:58 am|
|James Mitchell||Jul 19, 2006 11:13 am|
|Craig McClanahan||Jul 19, 2006 1:42 pm|
|Sean Schofield||Jul 19, 2006 1:54 pm|
|Craig McClanahan||Jul 19, 2006 2:15 pm|
|Greg Reddin||Jul 19, 2006 2:34 pm|
|Sean Schofield||Jul 19, 2006 3:41 pm|
|Wendy Smoak||Jul 19, 2006 9:37 pm|
|Greg Reddin||Jul 20, 2006 9:44 am|
|Wendy Smoak||Jul 20, 2006 12:48 pm|
|Greg Reddin||Jul 20, 2006 1:23 pm|
|Wendy Smoak||Jul 20, 2006 2:02 pm|
|Greg Reddin||Jul 20, 2006 4:32 pm|
|Wendy Smoak||Jul 20, 2006 10:49 pm|
|James Mitchell||Jul 23, 2006 11:01 am|
|Greg Reddin||Jul 23, 2006 2:36 pm|
|Craig McClanahan||Jul 23, 2006 5:02 pm|
|James Mitchell||Jul 25, 2006 7:07 am|
|Craig McClanahan||Jul 25, 2006 9:24 am|
|James Mitchell||Jul 27, 2006 9:41 pm|
|Craig McClanahan||Jul 28, 2006 8:20 pm|
|Sean Schofield||Jul 29, 2006 6:17 am|
|Wendy Smoak||Jul 29, 2006 6:59 am|
|Sean Schofield||Jul 29, 2006 9:48 am|
|Craig McClanahan||Jul 29, 2006 10:18 am|
|Craig McClanahan||Jul 29, 2006 10:23 am|
|Sean Schofield||Jul 29, 2006 5:30 pm|
|Craig McClanahan||Jul 29, 2006 9:32 pm|
|Greg Reddin||Jul 30, 2006 4:46 pm|
|Subject:||Re: Source Repository Organization and Release Strategy Thoughts|
|From:||Craig McClanahan (crai...@apache.org)|
|Date:||Jul 18, 2006 4:53:10 pm|
On 7/18/06, Sean Schofield <sean...@gmail.com> wrote:
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.
I think you'd likely get takers ... and I'd like to help.
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.
The mechanism we have for publishing examples is pretty scalable ... each example stands on its own and doesn't affect the size of the framework download. Therefore, I don't think its necessarily a bad thing for examples to have overlapping sets of functionality, because they will likely focus on different combinations of features to show off together. Therefore, I don't think there would be any reason not to want the app you described above.
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.
JPA is supported ... at least by Spring 2. However, if you aren't using Spring for anything else it's a lot of extra conceptual overhead to *require* it ... JPA + JSF handle all the basic stuff already (dependency injection, transactions, etc.).
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.
Sounds like this might really be a series of sample apps that share a common persistence tier -- and that would be a good thing. We definitely can use examples that go beyond the "hello, world" level of some potential ways to integrate these technologies together.
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.
I'd love to see something like this in Shale (presuming you're using Shale as part of the infrastructure, of course :-).
Thinking a bit further, we might want to also toy with the idea of an examples catalog that concisely documents the technologies featured in each example, plus a consistent format for the website associated with each sample that discusses the design patterns employed, highlights interesting implementation points, and mentions alternative approaches.
On 7/17/06, Craig McClanahan <crai...@apache.org> 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 :-).