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.
