Firstly, I'm not against merging. But obviously there are a couple of differences in goals and style that need to be addressed properly beforehand, since it implies a lot of (tedious) work. I still hope that we can, at least, factor out common parts (btw. honey-excel is already such a completely independent drop-in jar, if not a particularly impressive one;).
One of the targets I wanted to pursue with honeycomb was to get people started rapidly with everything they'll need to build a typical web-app, full-stack, one-stop. Maybe, changing the name from the original 'KickStart' was misleading, after all. That goal is not impossible to achieve as a collection of pluggable modules. But I like the idea of starting with a working application template and then move out modules as independent chunks as a refactoring effort. The most prominent difference in design is, that I want to have session-per-conversation. Honeycomb is not (only) a toy for me. I've 2 productive app based on it. And my experience is that it works. It may need work for other types of applications, though. Up to now, to me, spring (and tapernate) seem to treat hibernate-sessions too much like transactions while they really are working-sets of persistent entities (or 1st level caches, if you want). But I've just seen that James wants to go for conversations (even parallel named ones, which honeycomb has not yet)... . And lastly, call me stubborn ;-), I still don't see the point in adding spring. I'd be fine with it, as long as it doesn't break something, but that's about it. So, trying honeycomb should not take more than half an hour. I'm sure tapernate will not take longer. Just go with the one you like best. > -----Original Message----- > From: Hugo Palma [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 03, 2006 4:31 PM > To: Tapestry users > Subject: Re: Honeycomb vs Tapernate or Honeycomb with Tapernate > > > I agree that tapernate feels more hibernish then honeycomb. > > I guess the suggestion here would be to break honeycomb into several > plugable jars each one providing an integration with a > different technology. > One of these could then could be a merge of tapernate and honeycomb > hibernate integration. > Sounds good to me........ > > > On 5/3/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote: > > > > As much as I'd like to be loyal to honeycomb, when it came down to > > evaluating both and choosing one to reccomend to a client I > ended up going > > with tapernate. > > > > I feel it most closely fits in with the style of > development that tapestry > > and hivemind both try to achieve. (funny that, considering > that James is > > one > > of the core hivemind devs ;) ) > > > > It would be nice to see the two merge or at least come to > an agreement. I > > probably shouldn't get involved in giving opinions but since my only > > loyalty > > seems to be to the best of for any given technology that's > how it is... > > > > I will probably be trying to find a way to add the jms / > drools / etc > > logic > > into one of the drop in jar sort of libraries being managed over on > > javaforge. > > > > On 5/3/06, James Carman <[EMAIL PROTECTED]> wrote: > > > > > > I don't know about that, necessarily. We have discussed > it in the past. > > > However, the scope of Tapernate is less than what > Honeycomb is trying to > > > achieve. Tapernate is supposed to be the "way to do > hibernate within > > > tapestry." But, Honeycomb has other pieces (auditing, > excel exporting, > > > etc.) to it that don't fit into the Tapernate scope. > > > > > > The way I see it, Honeycomb should be written on top of > Tapernate (at > > > least > > > the parts that require persistence) as a library of > useful tapestry > > > utilities. However, putting them all in the same jar > doesn't allow you > > to > > > use it as separate "drop-in" jars. If it were me, I > would separate the > > > stuff out into multiple jar files so the user can pick > and choose what > > > they > > > want to enable. And, when they're placed on the classpath, the > > libraries > > > should weave themselves into the framework automatically > using either > > > configurations or overriding service implementations. > That's my vision > > > (and > > > the HiveMind vision), to create a vast library of these > drop-in jars > > that > > > will enable certain features when added to your > classpath. Of course, > > > that's exactly what Howard's [EMAIL PROTECTED] project > is all about. > > > There's my $0.02. > > > > > > -----Original Message----- > > > From: Hugo Palma [mailto:[EMAIL PROTECTED] > > > Sent: Wednesday, May 03, 2006 9:55 AM > > > To: Tapestry users > > > Subject: Re: Honeycomb vs Tapernate or Honeycomb with Tapernate > > > > > > I see that. So what you're trying to say is that > tapernate and honeycomb > > > approachs are too diferent implementation wise for them > to be merged > > into > > > a > > > single project ? > > > > > > On 5/3/06, James Carman <[EMAIL PROTECTED]> wrote: > > > > > > > > I chose to use the Spring stuff to manage the current > sessions and > > allow > > > > for > > > > declarative transaction demarcation since I know that > stuff works > > quite > > > > well. I don't use Spring IoC at all. I just added the > Spring stuff > > > into > > > > my > > > > HiveMind "object soup." > > > > > > > > > > > > -----Original Message----- > > > > From: Hugo Palma [mailto:[EMAIL PROTECTED] > > > > Sent: Wednesday, May 03, 2006 9:41 AM > > > > To: Tapestry users > > > > Subject: Re: Honeycomb vs Tapernate or Honeycomb with Tapernate > > > > > > > > That's one of the differences in implementation that i > found. But i > > > don't > > > > see that as a something that will drive my choice, as > long as i don't > > > have > > > > to use Spring IOC(hivemind will do just fine) for me > it's just another > > > jar > > > > in the classpath. > > > > > > > > On 5/3/06, James Carman <[EMAIL PROTECTED]> wrote: > > > > > > > > > > One big difference is the usage of the Spring classes within > > > Tapernate. > > > > > This is just a difference of opinion/direction. > > > > > > > > > > -----Original Message----- > > > > > From: Hugo Palma [mailto:[EMAIL PROTECTED] > > > > > Sent: Wednesday, May 03, 2006 9:04 AM > > > > > To: Tapestry users > > > > > Subject: Honeycomb vs Tapernate or Honeycomb with Tapernate > > > > > > > > > > Hi all, > > > > > > > > > > i've just started thinking about how Tapestry is > going to be used in > > a > > > > new > > > > > project at work. One of the decisions is how the > integration with > > > > > hibernate > > > > > is going to be implemented, i'm guessing 95% of > Tapestry projects > > goes > > > > > through this. With this in mind i took a look at > Honeycomb and at > > > > > Tapernate. > > > > > They both look great and seem to provide just what i > need to this > > > > project. > > > > > Although this is good, it leaves me with a problem, > which one ? > > > > > > > > > > As i look deeply into each one i find some differences in > > > > > implementation/usage of the same feature, some > features that are > > > > > implemented > > > > > in honeycomb and not tapernate and vice-versa, but > mainly i see a > > > > project > > > > > goal difference. It seems that honeycomb looks to not > only provide > > > > > integration with hibernate but with other libraries > that might be > > > useful > > > > > in > > > > > a web project, tapernate only goal is to implement the > > > > tapestry+hibernate > > > > > integration. > > > > > > > > > > With this, some doubts came to mind. > > > > > > > > > > Why are there two projects for this ? > > > > > Wouldn't it be better for both projects if they would > join forces ? > > If > > > > so, > > > > > shouldn't tapernate be included/merged into > honeycombs hibernate > > > > > integration > > > > > ? > > > > > > > > > > > > > > > What do you guys think ? > > > > > > > > > > Cheers > > > > > > > > > > Hugo > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > > For additional commands, e-mail: > > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: > [EMAIL PROTECTED] > > > For additional commands, e-mail: > [EMAIL PROTECTED] > > > > > > > > > > > > -- > > Jesse Kuhnert > > Tacos/Tapestry, team member/developer > > > > Open source based consulting work centered around > > dojo/tapestry/tacos/hivemind. > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
