You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@roller.apache.org by Anil Gangolli <an...@busybuddha.org> on 2006/08/16 18:41:16 UTC
Let's pick an implementation (was Re: New roller persistence implementation)
I support Elias's option #2 with some concessions to #1.
My strategy in similar situations would actually be to pick the
implementation and then code to its best-supported API.
Here's what I do support:
(a) Pick one and only one Apache-license-compatible ORM/persistence layer
*implementation* that we can distribute and whose use in Roller we will
support. It must be robust, reasonably efficient, and work over popular SQL
variants without us having to do a lot of our own work. (Hibernate has all
of these properties except ASF-license compatibility.)
(b) While it is definitely not a priority for me, I'm just fine with
architecting for
pluggability in order to help us switch later more easily if we need to.
However, I would only want to support the use of one API and in fact only
one implementation of that API in practice. If it happens that developers
can plug in something else at whatever level, they would be welcome to, but
they would basically be on their own. (Patches would be welcome along the
usual lines of course, but we wouldn't necessarily treat issues experienced
only on some alternate implementation as a bug.)
--a.
----- Original Message -----
From: "Elias Torres" <el...@torrez.us>
To: <ro...@incubator.apache.org>
Sent: Wednesday, August 16, 2006 5:42 AM
Subject: A forgotten option: iBatis (was Re: New roller persistence
implementation)
>
> I share some of the concerns that Jeff is bringing up in his mail and
> remember that long time ago Ted Husted had offered [1] to replace our
> Hibernate backend with iBatis or Cayenne. At the time, Dave said no
> thank you because Craig was working on JDO, but I hear mixed reviews on
> the work:
>
> 1. Some think that a pluggable strategy is good
> 2. Some would like to just pick one and move on
> 3. Some think is necessary just for license and we should always use
> hibernate
>
> We are fine with #1 and #2 not with #3. Therefore, I want to provide
> more support for #1 and #2 and suggest that if we have a pluggable
> strategy we could work on an iBatis implementation, maybe Ted will help
> us. If we choose #2, we would support an iBatis implementation. I think
> you get where I'm going. We are using iBatis internally in different
> projects and the experience has been good so far.
>
> I would love to hear your opinion on this.
>
> -Elias
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Henri Yandell <fl...@gmail.com>.
That's where I get fuzzy (and why I've taken some time to ponder a reply).
The below is my understanding of the policy, and I've talked to Cliff
a lot about it so am pretty sure I'm not saying anything incorrect. We
can't distribute LGPL, but we can decide to ship an incomplete product
that people have to actively plug the non-distributable dependencies
into (a system requirement). A more obvious example is a JVM - there
aren't any complete JVMs out there that we could ship, but every Java
project requires it.
The 'we' there is the fuzzy bit. It's described as the PMC of the
project, so that means that Roller can ship with a Hibernate system
requirement if and only if the Incubator PMC decide to do that.
So I don't know. I think we're going to need to come up with a list of
things left to do before graduation, then after finishing off as many
as we feel we want can we need to ask the PMC if we can graduate. I'll
kick that off in a different thread.
Hen
On 8/21/06, Dave Johnson <sn...@gmail.com> wrote:
> That's pretty good. We're not being forced to ditch Hibernate, but
> it's in our best interest to do so -- to make installation easier and
> to benefit the parts of the community that have problems with LGPL.
> And it seems to imply that we can graduate from the incubator in our
> current state and only bring in a new persistence layer when we (and
> the implementation) are good and ready.
>
> Or am I reading that wrong?
>
> - Dave
>
>
>
> On 8/21/06, Henri Yandell <fl...@gmail.com> wrote:
> > On 8/16/06, Dave Johnson <sn...@gmail.com> wrote:
> > > On 8/16/06, Allen Gilliland <al...@sun.com> wrote:
> > > > The first thing I would like to know is what the final apache stance is
> > > > on our use of Hibernate. Maybe it's just me, but it hasn't been totally
> > > > clear on what exactly our options are. I know that apache doesn't like
> > > > LGPL libraries, but I thought at some point there was some discussion
> > > > that we may be able to keep Hibernate in some situations. i.e. if we
> > > > were using hibernate through an open api like JPA or if there was some
> > > > form of alternative also available. In any case, I would like to get a
> > > > firm statement from apache about our options before I make any decisions
> > > > about what to do. can someone provide an official stance from apache?
> > >
> > > Yes. I would like that too. I've never seen the official Apache policy
> > > on projects shipping or depending on LGPL. Does one exist yet?
> > >
> > > I added Cliff Scmidt to the CC list.
> >
> > http://people.apache.org/~cliffs/3party.html is still as official as
> > it gets - it's 98% official though. We (everyone at the ASF) are
> > leaping in and using it. Cliff has some changes to make before
> > releasing it to www.apache, but they're not ground breaking changes as
> > far as I understand.
> >
> > LGPL policy:
> >
> > * We may not distribute LGPL licensed works.
> > * We can depend on LGPL licensed works, provided the user is aware of
> > this before using our product (forcing them to go download it from the
> > original source being the simplest and best way).
> >
> > The first is because LGPL is still the most weakly worded of the soft
> > copyleft licenses. The other main ones can be distributed, but LGPL
> > cannot.
> >
> > The second makes clearer sense if you consider the LGPL editor that
> > Roller used to ship with. After installing that as a blog server, the
> > Roller instance is still distributing that editor out to everyone and
> > so the owners of the blog server are now distributing LGPL. This may
> > or may not be something they are comfortable with.
> >
> > For a solely back-end dependency like Hibernate, distribution is only
> > going to be when somebody ships an enhanced version of Roller - which
> > isn't as unlikely as it sounds given that Roller seems to be doing
> > well in the enterprise in-house market.
> >
> > So officially - the choice for Apache Roller is between shipping
> > without a persistence layer and having the user add it later; and
> > finding a new persistence API.
> >
> > As it's a new policy, there's always a chance that the former for the
> > long term would incite community-wide unhappiness - it's hard to get a
> > consensus for what the consensus is on soft-copyleft licenses.
> >
> > Hen
> >
>
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Lindsey <dl...@gmail.com>.
Sure, if you like a lowest-common-denominator solution. But it doesn't
matter, these guys are sold on the coming Apache inplementation.
On 8/21/06, paksegu <pa...@yahoo.com> wrote:
>
> Yes but using JPA as a persitent layer gives you the flexibility to use
> other data
> store technologies like (Hibernate, JPOX and etc)
>
> Dave Lindsey <dl...@gmail.com> wrote: JPA is less flexable and
> apparently only a subset of what is available in
> JPOX.
>
> http://www.jpox.org/docs/1_2/jdovsjpa.html
>
> On 8/21/06, paksegu
> wrote:
> >
> > From what I read JPA can be used as the persistent layer for Hibernate,
> > JPOX and as well as EJB 3.
> >
> > Dave Lindsey wrote: Seems like performance should
> > be considered, not to mention using a
> > standards-based solution.
> >
> > http://www.jpox.org/docs/performance.html
> >
> >
> >
> > Ransford Segu-Baffoe
> >
> > paksegu@yahoo.com
> > paksegu@noqturnalmediasystems.com
> >
> > http://www.noqturnalmediasystems.com/
> > http://www.noqturnalmediasystems.com/Serenade/
> > https://serenade.dev.java.net/
> >
> > ---------------------------------
> > Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
> > countries) for 2¢/min or less.
> >
>
>
>
>
> Ransford Segu-Baffoe
>
> paksegu@yahoo.com
> paksegu@noqturnalmediasystems.com
>
> http://www.noqturnalmediasystems.com/
> http://www.noqturnalmediasystems.com/Serenade/
> https://serenade.dev.java.net/
>
> ---------------------------------
> Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
> countries) for 2¢/min or less.
>
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by paksegu <pa...@yahoo.com>.
Yes but using JPA as a persitent layer gives you the flexibility to use other data
store technologies like (Hibernate, JPOX and etc)
Dave Lindsey <dl...@gmail.com> wrote: JPA is less flexable and apparently only a subset of what is available in
JPOX.
http://www.jpox.org/docs/1_2/jdovsjpa.html
On 8/21/06, paksegu
wrote:
>
> From what I read JPA can be used as the persistent layer for Hibernate,
> JPOX and as well as EJB 3.
>
> Dave Lindsey wrote: Seems like performance should
> be considered, not to mention using a
> standards-based solution.
>
> http://www.jpox.org/docs/performance.html
>
>
>
> Ransford Segu-Baffoe
>
> paksegu@yahoo.com
> paksegu@noqturnalmediasystems.com
>
> http://www.noqturnalmediasystems.com/
> http://www.noqturnalmediasystems.com/Serenade/
> https://serenade.dev.java.net/
>
> ---------------------------------
> Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
> countries) for 2¢/min or less.
>
Ransford Segu-Baffoe
paksegu@yahoo.com
paksegu@noqturnalmediasystems.com
http://www.noqturnalmediasystems.com/
http://www.noqturnalmediasystems.com/Serenade/
https://serenade.dev.java.net/
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Lindsey <dl...@gmail.com>.
JPA is less flexable and apparently only a subset of what is available in
JPOX.
http://www.jpox.org/docs/1_2/jdovsjpa.html
On 8/21/06, paksegu <pa...@yahoo.com> wrote:
>
> From what I read JPA can be used as the persistent layer for Hibernate,
> JPOX and as well as EJB 3.
>
> Dave Lindsey <dl...@gmail.com> wrote: Seems like performance should
> be considered, not to mention using a
> standards-based solution.
>
> http://www.jpox.org/docs/performance.html
>
>
>
> Ransford Segu-Baffoe
>
> paksegu@yahoo.com
> paksegu@noqturnalmediasystems.com
>
> http://www.noqturnalmediasystems.com/
> http://www.noqturnalmediasystems.com/Serenade/
> https://serenade.dev.java.net/
>
> ---------------------------------
> Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+
> countries) for 2¢/min or less.
>
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by paksegu <pa...@yahoo.com>.
>From what I read JPA can be used as the persistent layer for Hibernate, JPOX and as well as EJB 3.
Dave Lindsey <dl...@gmail.com> wrote: Seems like performance should be considered, not to mention using a
standards-based solution.
http://www.jpox.org/docs/performance.html
Ransford Segu-Baffoe
paksegu@yahoo.com
paksegu@noqturnalmediasystems.com
http://www.noqturnalmediasystems.com/
http://www.noqturnalmediasystems.com/Serenade/
https://serenade.dev.java.net/
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Lindsey <dl...@gmail.com>.
Seems like performance should be considered, not to mention using a
standards-based solution.
http://www.jpox.org/docs/performance.html
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Johnson <sn...@gmail.com>.
That's pretty good. We're not being forced to ditch Hibernate, but
it's in our best interest to do so -- to make installation easier and
to benefit the parts of the community that have problems with LGPL.
And it seems to imply that we can graduate from the incubator in our
current state and only bring in a new persistence layer when we (and
the implementation) are good and ready.
Or am I reading that wrong?
- Dave
On 8/21/06, Henri Yandell <fl...@gmail.com> wrote:
> On 8/16/06, Dave Johnson <sn...@gmail.com> wrote:
> > On 8/16/06, Allen Gilliland <al...@sun.com> wrote:
> > > The first thing I would like to know is what the final apache stance is
> > > on our use of Hibernate. Maybe it's just me, but it hasn't been totally
> > > clear on what exactly our options are. I know that apache doesn't like
> > > LGPL libraries, but I thought at some point there was some discussion
> > > that we may be able to keep Hibernate in some situations. i.e. if we
> > > were using hibernate through an open api like JPA or if there was some
> > > form of alternative also available. In any case, I would like to get a
> > > firm statement from apache about our options before I make any decisions
> > > about what to do. can someone provide an official stance from apache?
> >
> > Yes. I would like that too. I've never seen the official Apache policy
> > on projects shipping or depending on LGPL. Does one exist yet?
> >
> > I added Cliff Scmidt to the CC list.
>
> http://people.apache.org/~cliffs/3party.html is still as official as
> it gets - it's 98% official though. We (everyone at the ASF) are
> leaping in and using it. Cliff has some changes to make before
> releasing it to www.apache, but they're not ground breaking changes as
> far as I understand.
>
> LGPL policy:
>
> * We may not distribute LGPL licensed works.
> * We can depend on LGPL licensed works, provided the user is aware of
> this before using our product (forcing them to go download it from the
> original source being the simplest and best way).
>
> The first is because LGPL is still the most weakly worded of the soft
> copyleft licenses. The other main ones can be distributed, but LGPL
> cannot.
>
> The second makes clearer sense if you consider the LGPL editor that
> Roller used to ship with. After installing that as a blog server, the
> Roller instance is still distributing that editor out to everyone and
> so the owners of the blog server are now distributing LGPL. This may
> or may not be something they are comfortable with.
>
> For a solely back-end dependency like Hibernate, distribution is only
> going to be when somebody ships an enhanced version of Roller - which
> isn't as unlikely as it sounds given that Roller seems to be doing
> well in the enterprise in-house market.
>
> So officially - the choice for Apache Roller is between shipping
> without a persistence layer and having the user add it later; and
> finding a new persistence API.
>
> As it's a new policy, there's always a chance that the former for the
> long term would incite community-wide unhappiness - it's hard to get a
> consensus for what the consensus is on soft-copyleft licenses.
>
> Hen
>
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Henri Yandell <fl...@gmail.com>.
On 8/16/06, Dave Johnson <sn...@gmail.com> wrote:
> On 8/16/06, Allen Gilliland <al...@sun.com> wrote:
> > The first thing I would like to know is what the final apache stance is
> > on our use of Hibernate. Maybe it's just me, but it hasn't been totally
> > clear on what exactly our options are. I know that apache doesn't like
> > LGPL libraries, but I thought at some point there was some discussion
> > that we may be able to keep Hibernate in some situations. i.e. if we
> > were using hibernate through an open api like JPA or if there was some
> > form of alternative also available. In any case, I would like to get a
> > firm statement from apache about our options before I make any decisions
> > about what to do. can someone provide an official stance from apache?
>
> Yes. I would like that too. I've never seen the official Apache policy
> on projects shipping or depending on LGPL. Does one exist yet?
>
> I added Cliff Scmidt to the CC list.
http://people.apache.org/~cliffs/3party.html is still as official as
it gets - it's 98% official though. We (everyone at the ASF) are
leaping in and using it. Cliff has some changes to make before
releasing it to www.apache, but they're not ground breaking changes as
far as I understand.
LGPL policy:
* We may not distribute LGPL licensed works.
* We can depend on LGPL licensed works, provided the user is aware of
this before using our product (forcing them to go download it from the
original source being the simplest and best way).
The first is because LGPL is still the most weakly worded of the soft
copyleft licenses. The other main ones can be distributed, but LGPL
cannot.
The second makes clearer sense if you consider the LGPL editor that
Roller used to ship with. After installing that as a blog server, the
Roller instance is still distributing that editor out to everyone and
so the owners of the blog server are now distributing LGPL. This may
or may not be something they are comfortable with.
For a solely back-end dependency like Hibernate, distribution is only
going to be when somebody ships an enhanced version of Roller - which
isn't as unlikely as it sounds given that Roller seems to be doing
well in the enterprise in-house market.
So officially - the choice for Apache Roller is between shipping
without a persistence layer and having the user add it later; and
finding a new persistence API.
As it's a new policy, there's always a chance that the former for the
long term would incite community-wide unhappiness - it's hard to get a
consensus for what the consensus is on soft-copyleft licenses.
Hen
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Johnson <sn...@gmail.com>.
On 8/16/06, Allen Gilliland <al...@sun.com> wrote:
> The first thing I would like to know is what the final apache stance is
> on our use of Hibernate. Maybe it's just me, but it hasn't been totally
> clear on what exactly our options are. I know that apache doesn't like
> LGPL libraries, but I thought at some point there was some discussion
> that we may be able to keep Hibernate in some situations. i.e. if we
> were using hibernate through an open api like JPA or if there was some
> form of alternative also available. In any case, I would like to get a
> firm statement from apache about our options before I make any decisions
> about what to do. can someone provide an official stance from apache?
Yes. I would like that too. I've never seen the official Apache policy
on projects shipping or depending on LGPL. Does one exist yet?
I added Cliff Scmidt to the CC list.
- Dave
Re: Let's pick an implementation (was Re: New roller persistence
implementation)
Posted by Allen Gilliland <al...@sun.com>.
Dave Johnson wrote:
> On 8/16/06, Elias Torres <el...@torrez.us> wrote:
>> I think we have heard enough opinions from many in the community. Should
>> we try to vote on the issue and decide? The options are many all
>> hovering on things from the set keeping hibernate, staying at apache,
>> Sun leaving roller, IBM leaving roller, making it pluggable, replace the
>> ORM, rewrite it in Ruby, Lisp, ML and any combination of any of these.
>
> Personally, I don't see a crisis or a need for a vote.
>
> Craig would like to develop an alternative backend for Roller. I don't
> think we need to vote to permit him to do that in the sandbox or in a
> separate banch.
>
> Those that wish to help Craig suceed should help him by reviewing his
> design, suggesting improvements and assisting with implementation.
> When/if Craig and friends come up with an implementation or two we can
> evaluate it and then decide what to do -- with a vote if necessary.
That sounds good to me, but I don't think that means we should stop
discussing the issue. We still need to figure out our general approach
to this problem as a community.
The first thing I would like to know is what the final apache stance is
on our use of Hibernate. Maybe it's just me, but it hasn't been totally
clear on what exactly our options are. I know that apache doesn't like
LGPL libraries, but I thought at some point there was some discussion
that we may be able to keep Hibernate in some situations. i.e. if we
were using hibernate through an open api like JPA or if there was some
form of alternative also available. In any case, I would like to get a
firm statement from apache about our options before I make any decisions
about what to do. can someone provide an official stance from apache?
-- Allen
>
> - Dave
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Johnson <sn...@gmail.com>.
On 8/16/06, Elias Torres <el...@torrez.us> wrote:
> I think we have heard enough opinions from many in the community. Should
> we try to vote on the issue and decide? The options are many all
> hovering on things from the set keeping hibernate, staying at apache,
> Sun leaving roller, IBM leaving roller, making it pluggable, replace the
> ORM, rewrite it in Ruby, Lisp, ML and any combination of any of these.
Personally, I don't see a crisis or a need for a vote.
Craig would like to develop an alternative backend for Roller. I don't
think we need to vote to permit him to do that in the sandbox or in a
separate banch.
Those that wish to help Craig suceed should help him by reviewing his
design, suggesting improvements and assisting with implementation.
When/if Craig and friends come up with an implementation or two we can
evaluate it and then decide what to do -- with a vote if necessary.
- Dave
Re: Let's pick an implementation (was Re: New roller persistence
implementation)
Posted by Elias Torres <el...@torrez.us>.
Right on. Roller was part of a couple of studies at Forrester Research
and we did not fare too well. We understand why but we have faith in its
potential and would like to see it taken to a next level. The main
reason behind Roller lower ratings seem to be lack of vendor support as
opposed to iUpload, MovableType, WordPress, Blogger, etc.
This is more than just Hibernate and Apache, like you said, it's more
about what we can do in the future for our users by improving its
support and development through more resources.
Roller is definitely growing up!
-Elias
paksegu wrote:
> I am not a Developer on the Roller team so I now my inputs are somehow limited, however from a Developers standpoint it makes no sense replacing hibernate just to graduate from Apache. On the other hand, from a business standpoint it make absolute sense when you intend to create a business model out of Rolller and distribute it commercially; you will come across a costly barrier imposed by Hibernate GPL license unless your intention for Roller to be used non commercial or proprietary environment. Having the flexibility of Apache license creates more business opportunities which turns out great for Roller in respect that we can have afford to get developers to commit to the success of Roller
>
>
>
> Elias Torres <el...@torrez.us> wrote:
>
> Allen Gilliland wrote:
>> The difference is partly a shift in my viewpoint and partly a shift in
>> my intentions with each email. I never changed my opinion on my support
>> for Hibernate, but what has changed as the discussion has grown is how
>> willing I am to support the alternatives.
>>
>> First off, I should make clear that I don't speak for Sun, I speak for
>> myself and to some degree on the behalf of the team I with that is
>> responsible for running blogs.sun.com. My job is to run that website
>> and the decisions I make with regards to Roller are always influenced by
>> what I think is best for blogs.sun.com.
>>
>> I had originally been more open in my discussion about the various
>> approaches that could be taken around the persistence implementation
>> mostly because I had for one reason or another felt that folks on this
>> list had already made up their mind to replace Hibernate despite my
>> objections. Part of me thinks that's okay and I am not entirely opposed
>> to an alternate approach, but as I thought about it more realistically
>> it seems less and less like a good idea and that's where my last email
>> came from.
>>
>> You said that Hibernate is a thorn in your side, so you obviously you
>> favor replacing it, but we don't have that problem and AFAIK there
>> aren't any other Roller users who have complained about that. If we
>> don't have a problem with using Hibernate when why should we want to
>> replace it? I don't think there are any benefits at all for us to
>> replace Hibernate.
>
> That might definitely be true. The benefits to most Roller
> users/installers by us changing could at best be none, if anything it
> will be growing pains all over.
>
>> I am always open to options, but you have to tell me why we should
>> replace Hibernate? If the only reason is because of an issue with
>> apache licensing then that's not good enough in my opinion.
>
> IBM's reason is simply a license issue and so is Apache's reason. If I
> were to speak on the matter personally, this whole issue definitely
> stinks. However, as an IBM employee I have to comply with the company's
> policies and we cannot afford to be involved in licensing lawsuits and
> that's more than good enough for me in my opinion.
>
> I'm in no way advocating that we make our users deal with the pain and
> that's why I want to entertain the pluggable option. Dave's OpenJPA
> suggestion sounds plausible (as long as there's a Apache-licensed JPA
> implementation that's been proven or simply works).
>
> I think we have heard enough opinions from many in the community. Should
> we try to vote on the issue and decide? The options are many all
> hovering on things from the set keeping hibernate, staying at apache,
> Sun leaving roller, IBM leaving roller, making it pluggable, replace the
> ORM, rewrite it in Ruby, Lisp, ML and any combination of any of these.
>
> I often share at IBM that Roller Team is 100% behind solving the
> Hibernate issue by satisfying Apache Licensing requirements and every
> month or so, we seem to waver at our initial commitment to make Roller
> an Apache project all for an ORM library. We are currently at a crucial
> moment in our decision to continue working with the Roller project and
> some clarification in the matter would help us to decide whether or not
> we would get more involved with Roller than we are today.
>
> What do you guys think? Can we try to make a decision? I'm all for what
> is best for the today's and future Roller users.
>
> -Elias
>
>> -- Allen
>>
>>
>> Elias Torres wrote:
>>> Allen,
>>>
>>> I note a stark difference between this email and one of the first emails
>>> from you in the thread:
>>>
>>> """
>>> assuming we agree that we are only focusing on implementing one of the
>>> options, we then need to decide which one. just so it's known, i think
>>> it's entirely lame that we are getting rid of Hibernate over a silly
>>> licensing issue. as a large roller customer i consider it more of a
>>> pain than a benefit to have to replace the backend. regardless of that
>>> fact, it appears that's what everyone wants to do, so i consider
>>> Hibernate to no longer be an option. that leaves JDO and JPA as you
>>> mentioned, and i don't really have any preference between the two. """
>>>
>>> Now it seems that the *only* option for you (is it for Sun, too?) is
>>> Hibernate. Is that correct? Why the change of opinion? If I may ask.
>>>
>>> -Elias
>>>
>>> Allen Gilliland wrote:
>>>> I still want more information about the soft vs. hard dependency issue
>>>> WRT Hibernate being part of the project, but whatever the outcome of
>>>> that is doesn't change the fact that I continue to support Hibernate as
>>>> our implementation.
>>>>
>>>> I should also say that depending on how this works out this is something
>>>> that could put us (blogs.sun.com) at odds with the community and
>>>> encourage us to go our own direction.
>>>>
>>>> My only concern is for my installation of Roller at blogs.sun.com and as
>>>> I've said before, switching to something other than Hibernate is only
>>>> going to create problems for us. As far as I'm concerned Hibernate
>>>> still offers the best option as the persistence implementation and since
>>>> the licensing issue does not affect us specifically then I don't see any
>>>> reason to mess with it. At some point we will likely be willing to try
>>>> a JPA implementation, but we are not really interested in being one of
>>>> the first adopters, so that won't happen for a while.
>>>>
>>>> Depending on the outcome of the soft vs. hard dependency issue and
>>>> whether or not apache will provide us some potential way to continue
>>>> using Hibernate legally is what will determine my final point of view.
>>>>
>>>> -- Allen
>>>>
>>>>
>>>> Dave Johnson wrote:
>>>>> On 8/16/06, Anil Gangolli wrote:
>>>>>> I support Elias's option #2 with some concessions to #1.
>>>>> I feel about the same way.
>>>>>
>>>>> On the question of "who here wants to replace Hibernate?"
>>>>>
>>>>> Hibernate's LGPL licensing is incompatible with Apache policy and
>>>>> there exists a set of contributors who are willing and able to provide
>>>>> an alternative backend impl. I'm a member of that set. If we create an
>>>>> alternative, it works well and we've got consensus then we'll ship it
>>>>> with Roller. Do we have to do this before we graduate? I sure as hell
>>>>> hope not.
>>>>>
>>>>> On the question of "which ORM should we choose?"
>>>>>
>>>>> I definitely believe we should ship one ORM with Roller and the Roller
>>>>> project should not do anything to promote, document or support the
>>>>> idea of users plugging in alternative ORMs.
>>>>>
>>>>> Personally I favor JPA because 1) there will be multiple high-quality
>>>>> implementatons (some at Apache) and 2) Hibernate is one of the
>>>>> implementations. So we'd ship OpenJPA or something similar, but folks
>>>>> who *really* want to continue using Hibernate can figure out on their
>>>>> own how to configure Roller to use Hibernate's JPA implementation.
>>>>>
>>>>> On the question of "Data Mapper good or bad?"
>>>>>
>>>>> I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
>>>>> ORM queries, just as our Persistence Strategy allows us to abstract
>>>>> ORM load/save operations. We'll have a complete persistence
>>>>> abstraction, something I've always wanted to see. The ability to
>>>>> compare JPA, JDO and possibly other ORMs seems like a key feature
>>>>> right now. Having named and externalized queries is nice too.
>>>>>
>>>>> - Dave
>
>
>
> Ransford Segu-Baffoe
>
> paksegu@yahoo.com
> paksegu@noqturnalmediasystems.com
>
> http://www.noqturnalmediasystems.com/
> http://www.noqturnalmediasystems.com/Serenade/
> https://serenade.dev.java.net/
>
> ---------------------------------
> Do you Yahoo!?
> Get on board. You're invited to try the new Yahoo! Mail Beta.
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by paksegu <pa...@yahoo.com>.
I am not a Developer on the Roller team so I now my inputs are somehow limited, however from a Developers standpoint it makes no sense replacing hibernate just to graduate from Apache. On the other hand, from a business standpoint it make absolute sense when you intend to create a business model out of Rolller and distribute it commercially; you will come across a costly barrier imposed by Hibernate GPL license unless your intention for Roller to be used non commercial or proprietary environment. Having the flexibility of Apache license creates more business opportunities which turns out great for Roller in respect that we can have afford to get developers to commit to the success of Roller
Elias Torres <el...@torrez.us> wrote:
Allen Gilliland wrote:
> The difference is partly a shift in my viewpoint and partly a shift in
> my intentions with each email. I never changed my opinion on my support
> for Hibernate, but what has changed as the discussion has grown is how
> willing I am to support the alternatives.
>
> First off, I should make clear that I don't speak for Sun, I speak for
> myself and to some degree on the behalf of the team I with that is
> responsible for running blogs.sun.com. My job is to run that website
> and the decisions I make with regards to Roller are always influenced by
> what I think is best for blogs.sun.com.
>
> I had originally been more open in my discussion about the various
> approaches that could be taken around the persistence implementation
> mostly because I had for one reason or another felt that folks on this
> list had already made up their mind to replace Hibernate despite my
> objections. Part of me thinks that's okay and I am not entirely opposed
> to an alternate approach, but as I thought about it more realistically
> it seems less and less like a good idea and that's where my last email
> came from.
>
> You said that Hibernate is a thorn in your side, so you obviously you
> favor replacing it, but we don't have that problem and AFAIK there
> aren't any other Roller users who have complained about that. If we
> don't have a problem with using Hibernate when why should we want to
> replace it? I don't think there are any benefits at all for us to
> replace Hibernate.
That might definitely be true. The benefits to most Roller
users/installers by us changing could at best be none, if anything it
will be growing pains all over.
>
> I am always open to options, but you have to tell me why we should
> replace Hibernate? If the only reason is because of an issue with
> apache licensing then that's not good enough in my opinion.
IBM's reason is simply a license issue and so is Apache's reason. If I
were to speak on the matter personally, this whole issue definitely
stinks. However, as an IBM employee I have to comply with the company's
policies and we cannot afford to be involved in licensing lawsuits and
that's more than good enough for me in my opinion.
I'm in no way advocating that we make our users deal with the pain and
that's why I want to entertain the pluggable option. Dave's OpenJPA
suggestion sounds plausible (as long as there's a Apache-licensed JPA
implementation that's been proven or simply works).
I think we have heard enough opinions from many in the community. Should
we try to vote on the issue and decide? The options are many all
hovering on things from the set keeping hibernate, staying at apache,
Sun leaving roller, IBM leaving roller, making it pluggable, replace the
ORM, rewrite it in Ruby, Lisp, ML and any combination of any of these.
I often share at IBM that Roller Team is 100% behind solving the
Hibernate issue by satisfying Apache Licensing requirements and every
month or so, we seem to waver at our initial commitment to make Roller
an Apache project all for an ORM library. We are currently at a crucial
moment in our decision to continue working with the Roller project and
some clarification in the matter would help us to decide whether or not
we would get more involved with Roller than we are today.
What do you guys think? Can we try to make a decision? I'm all for what
is best for the today's and future Roller users.
-Elias
>
> -- Allen
>
>
> Elias Torres wrote:
>> Allen,
>>
>> I note a stark difference between this email and one of the first emails
>> from you in the thread:
>>
>> """
>> assuming we agree that we are only focusing on implementing one of the
>> options, we then need to decide which one. just so it's known, i think
>> it's entirely lame that we are getting rid of Hibernate over a silly
>> licensing issue. as a large roller customer i consider it more of a
>> pain than a benefit to have to replace the backend. regardless of that
>> fact, it appears that's what everyone wants to do, so i consider
>> Hibernate to no longer be an option. that leaves JDO and JPA as you
>> mentioned, and i don't really have any preference between the two. """
>>
>> Now it seems that the *only* option for you (is it for Sun, too?) is
>> Hibernate. Is that correct? Why the change of opinion? If I may ask.
>>
>> -Elias
>>
>> Allen Gilliland wrote:
>>> I still want more information about the soft vs. hard dependency issue
>>> WRT Hibernate being part of the project, but whatever the outcome of
>>> that is doesn't change the fact that I continue to support Hibernate as
>>> our implementation.
>>>
>>> I should also say that depending on how this works out this is something
>>> that could put us (blogs.sun.com) at odds with the community and
>>> encourage us to go our own direction.
>>>
>>> My only concern is for my installation of Roller at blogs.sun.com and as
>>> I've said before, switching to something other than Hibernate is only
>>> going to create problems for us. As far as I'm concerned Hibernate
>>> still offers the best option as the persistence implementation and since
>>> the licensing issue does not affect us specifically then I don't see any
>>> reason to mess with it. At some point we will likely be willing to try
>>> a JPA implementation, but we are not really interested in being one of
>>> the first adopters, so that won't happen for a while.
>>>
>>> Depending on the outcome of the soft vs. hard dependency issue and
>>> whether or not apache will provide us some potential way to continue
>>> using Hibernate legally is what will determine my final point of view.
>>>
>>> -- Allen
>>>
>>>
>>> Dave Johnson wrote:
>>>> On 8/16/06, Anil Gangolli wrote:
>>>>> I support Elias's option #2 with some concessions to #1.
>>>> I feel about the same way.
>>>>
>>>> On the question of "who here wants to replace Hibernate?"
>>>>
>>>> Hibernate's LGPL licensing is incompatible with Apache policy and
>>>> there exists a set of contributors who are willing and able to provide
>>>> an alternative backend impl. I'm a member of that set. If we create an
>>>> alternative, it works well and we've got consensus then we'll ship it
>>>> with Roller. Do we have to do this before we graduate? I sure as hell
>>>> hope not.
>>>>
>>>> On the question of "which ORM should we choose?"
>>>>
>>>> I definitely believe we should ship one ORM with Roller and the Roller
>>>> project should not do anything to promote, document or support the
>>>> idea of users plugging in alternative ORMs.
>>>>
>>>> Personally I favor JPA because 1) there will be multiple high-quality
>>>> implementatons (some at Apache) and 2) Hibernate is one of the
>>>> implementations. So we'd ship OpenJPA or something similar, but folks
>>>> who *really* want to continue using Hibernate can figure out on their
>>>> own how to configure Roller to use Hibernate's JPA implementation.
>>>>
>>>> On the question of "Data Mapper good or bad?"
>>>>
>>>> I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
>>>> ORM queries, just as our Persistence Strategy allows us to abstract
>>>> ORM load/save operations. We'll have a complete persistence
>>>> abstraction, something I've always wanted to see. The ability to
>>>> compare JPA, JDO and possibly other ORMs seems like a key feature
>>>> right now. Having named and externalized queries is nice too.
>>>>
>>>> - Dave
>
Ransford Segu-Baffoe
paksegu@yahoo.com
paksegu@noqturnalmediasystems.com
http://www.noqturnalmediasystems.com/
http://www.noqturnalmediasystems.com/Serenade/
https://serenade.dev.java.net/
---------------------------------
Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.
Re: Let's pick an implementation (was Re: New roller persistence
implementation)
Posted by Elias Torres <el...@torrez.us>.
Allen Gilliland wrote:
> The difference is partly a shift in my viewpoint and partly a shift in
> my intentions with each email. I never changed my opinion on my support
> for Hibernate, but what has changed as the discussion has grown is how
> willing I am to support the alternatives.
>
> First off, I should make clear that I don't speak for Sun, I speak for
> myself and to some degree on the behalf of the team I with that is
> responsible for running blogs.sun.com. My job is to run that website
> and the decisions I make with regards to Roller are always influenced by
> what I think is best for blogs.sun.com.
>
> I had originally been more open in my discussion about the various
> approaches that could be taken around the persistence implementation
> mostly because I had for one reason or another felt that folks on this
> list had already made up their mind to replace Hibernate despite my
> objections. Part of me thinks that's okay and I am not entirely opposed
> to an alternate approach, but as I thought about it more realistically
> it seems less and less like a good idea and that's where my last email
> came from.
>
> You said that Hibernate is a thorn in your side, so you obviously you
> favor replacing it, but we don't have that problem and AFAIK there
> aren't any other Roller users who have complained about that. If we
> don't have a problem with using Hibernate when why should we want to
> replace it? I don't think there are any benefits at all for us to
> replace Hibernate.
That might definitely be true. The benefits to most Roller
users/installers by us changing could at best be none, if anything it
will be growing pains all over.
>
> I am always open to options, but you have to tell me why we should
> replace Hibernate? If the only reason is because of an issue with
> apache licensing then that's not good enough in my opinion.
IBM's reason is simply a license issue and so is Apache's reason. If I
were to speak on the matter personally, this whole issue definitely
stinks. However, as an IBM employee I have to comply with the company's
policies and we cannot afford to be involved in licensing lawsuits and
that's more than good enough for me in my opinion.
I'm in no way advocating that we make our users deal with the pain and
that's why I want to entertain the pluggable option. Dave's OpenJPA
suggestion sounds plausible (as long as there's a Apache-licensed JPA
implementation that's been proven or simply works).
I think we have heard enough opinions from many in the community. Should
we try to vote on the issue and decide? The options are many all
hovering on things from the set keeping hibernate, staying at apache,
Sun leaving roller, IBM leaving roller, making it pluggable, replace the
ORM, rewrite it in Ruby, Lisp, ML and any combination of any of these.
I often share at IBM that Roller Team is 100% behind solving the
Hibernate issue by satisfying Apache Licensing requirements and every
month or so, we seem to waver at our initial commitment to make Roller
an Apache project all for an ORM library. We are currently at a crucial
moment in our decision to continue working with the Roller project and
some clarification in the matter would help us to decide whether or not
we would get more involved with Roller than we are today.
What do you guys think? Can we try to make a decision? I'm all for what
is best for the today's and future Roller users.
-Elias
>
> -- Allen
>
>
> Elias Torres wrote:
>> Allen,
>>
>> I note a stark difference between this email and one of the first emails
>> from you in the thread:
>>
>> """
>> assuming we agree that we are only focusing on implementing one of the
>> options, we then need to decide which one. just so it's known, i think
>> it's entirely lame that we are getting rid of Hibernate over a silly
>> licensing issue. as a large roller customer i consider it more of a
>> pain than a benefit to have to replace the backend. regardless of that
>> fact, it appears that's what everyone wants to do, so i consider
>> Hibernate to no longer be an option. that leaves JDO and JPA as you
>> mentioned, and i don't really have any preference between the two. """
>>
>> Now it seems that the *only* option for you (is it for Sun, too?) is
>> Hibernate. Is that correct? Why the change of opinion? If I may ask.
>>
>> -Elias
>>
>> Allen Gilliland wrote:
>>> I still want more information about the soft vs. hard dependency issue
>>> WRT Hibernate being part of the project, but whatever the outcome of
>>> that is doesn't change the fact that I continue to support Hibernate as
>>> our implementation.
>>>
>>> I should also say that depending on how this works out this is something
>>> that could put us (blogs.sun.com) at odds with the community and
>>> encourage us to go our own direction.
>>>
>>> My only concern is for my installation of Roller at blogs.sun.com and as
>>> I've said before, switching to something other than Hibernate is only
>>> going to create problems for us. As far as I'm concerned Hibernate
>>> still offers the best option as the persistence implementation and since
>>> the licensing issue does not affect us specifically then I don't see any
>>> reason to mess with it. At some point we will likely be willing to try
>>> a JPA implementation, but we are not really interested in being one of
>>> the first adopters, so that won't happen for a while.
>>>
>>> Depending on the outcome of the soft vs. hard dependency issue and
>>> whether or not apache will provide us some potential way to continue
>>> using Hibernate legally is what will determine my final point of view.
>>>
>>> -- Allen
>>>
>>>
>>> Dave Johnson wrote:
>>>> On 8/16/06, Anil Gangolli <an...@busybuddha.org> wrote:
>>>>> I support Elias's option #2 with some concessions to #1.
>>>> I feel about the same way.
>>>>
>>>> On the question of "who here wants to replace Hibernate?"
>>>>
>>>> Hibernate's LGPL licensing is incompatible with Apache policy and
>>>> there exists a set of contributors who are willing and able to provide
>>>> an alternative backend impl. I'm a member of that set. If we create an
>>>> alternative, it works well and we've got consensus then we'll ship it
>>>> with Roller. Do we have to do this before we graduate? I sure as hell
>>>> hope not.
>>>>
>>>> On the question of "which ORM should we choose?"
>>>>
>>>> I definitely believe we should ship one ORM with Roller and the Roller
>>>> project should not do anything to promote, document or support the
>>>> idea of users plugging in alternative ORMs.
>>>>
>>>> Personally I favor JPA because 1) there will be multiple high-quality
>>>> implementatons (some at Apache) and 2) Hibernate is one of the
>>>> implementations. So we'd ship OpenJPA or something similar, but folks
>>>> who *really* want to continue using Hibernate can figure out on their
>>>> own how to configure Roller to use Hibernate's JPA implementation.
>>>>
>>>> On the question of "Data Mapper good or bad?"
>>>>
>>>> I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
>>>> ORM queries, just as our Persistence Strategy allows us to abstract
>>>> ORM load/save operations. We'll have a complete persistence
>>>> abstraction, something I've always wanted to see. The ability to
>>>> compare JPA, JDO and possibly other ORMs seems like a key feature
>>>> right now. Having named and externalized queries is nice too.
>>>>
>>>> - Dave
>
Re: Let's pick an implementation (was Re: New roller persistence
implementation)
Posted by Allen Gilliland <al...@sun.com>.
The difference is partly a shift in my viewpoint and partly a shift in
my intentions with each email. I never changed my opinion on my support
for Hibernate, but what has changed as the discussion has grown is how
willing I am to support the alternatives.
First off, I should make clear that I don't speak for Sun, I speak for
myself and to some degree on the behalf of the team I with that is
responsible for running blogs.sun.com. My job is to run that website
and the decisions I make with regards to Roller are always influenced by
what I think is best for blogs.sun.com.
I had originally been more open in my discussion about the various
approaches that could be taken around the persistence implementation
mostly because I had for one reason or another felt that folks on this
list had already made up their mind to replace Hibernate despite my
objections. Part of me thinks that's okay and I am not entirely opposed
to an alternate approach, but as I thought about it more realistically
it seems less and less like a good idea and that's where my last email
came from.
You said that Hibernate is a thorn in your side, so you obviously you
favor replacing it, but we don't have that problem and AFAIK there
aren't any other Roller users who have complained about that. If we
don't have a problem with using Hibernate when why should we want to
replace it? I don't think there are any benefits at all for us to
replace Hibernate.
I am always open to options, but you have to tell me why we should
replace Hibernate? If the only reason is because of an issue with
apache licensing then that's not good enough in my opinion.
-- Allen
Elias Torres wrote:
> Allen,
>
> I note a stark difference between this email and one of the first emails
> from you in the thread:
>
> """
> assuming we agree that we are only focusing on implementing one of the
> options, we then need to decide which one. just so it's known, i think
> it's entirely lame that we are getting rid of Hibernate over a silly
> licensing issue. as a large roller customer i consider it more of a
> pain than a benefit to have to replace the backend. regardless of that
> fact, it appears that's what everyone wants to do, so i consider
> Hibernate to no longer be an option. that leaves JDO and JPA as you
> mentioned, and i don't really have any preference between the two. """
>
> Now it seems that the *only* option for you (is it for Sun, too?) is
> Hibernate. Is that correct? Why the change of opinion? If I may ask.
>
> -Elias
>
> Allen Gilliland wrote:
>> I still want more information about the soft vs. hard dependency issue
>> WRT Hibernate being part of the project, but whatever the outcome of
>> that is doesn't change the fact that I continue to support Hibernate as
>> our implementation.
>>
>> I should also say that depending on how this works out this is something
>> that could put us (blogs.sun.com) at odds with the community and
>> encourage us to go our own direction.
>>
>> My only concern is for my installation of Roller at blogs.sun.com and as
>> I've said before, switching to something other than Hibernate is only
>> going to create problems for us. As far as I'm concerned Hibernate
>> still offers the best option as the persistence implementation and since
>> the licensing issue does not affect us specifically then I don't see any
>> reason to mess with it. At some point we will likely be willing to try
>> a JPA implementation, but we are not really interested in being one of
>> the first adopters, so that won't happen for a while.
>>
>> Depending on the outcome of the soft vs. hard dependency issue and
>> whether or not apache will provide us some potential way to continue
>> using Hibernate legally is what will determine my final point of view.
>>
>> -- Allen
>>
>>
>> Dave Johnson wrote:
>>> On 8/16/06, Anil Gangolli <an...@busybuddha.org> wrote:
>>>> I support Elias's option #2 with some concessions to #1.
>>> I feel about the same way.
>>>
>>> On the question of "who here wants to replace Hibernate?"
>>>
>>> Hibernate's LGPL licensing is incompatible with Apache policy and
>>> there exists a set of contributors who are willing and able to provide
>>> an alternative backend impl. I'm a member of that set. If we create an
>>> alternative, it works well and we've got consensus then we'll ship it
>>> with Roller. Do we have to do this before we graduate? I sure as hell
>>> hope not.
>>>
>>> On the question of "which ORM should we choose?"
>>>
>>> I definitely believe we should ship one ORM with Roller and the Roller
>>> project should not do anything to promote, document or support the
>>> idea of users plugging in alternative ORMs.
>>>
>>> Personally I favor JPA because 1) there will be multiple high-quality
>>> implementatons (some at Apache) and 2) Hibernate is one of the
>>> implementations. So we'd ship OpenJPA or something similar, but folks
>>> who *really* want to continue using Hibernate can figure out on their
>>> own how to configure Roller to use Hibernate's JPA implementation.
>>>
>>> On the question of "Data Mapper good or bad?"
>>>
>>> I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
>>> ORM queries, just as our Persistence Strategy allows us to abstract
>>> ORM load/save operations. We'll have a complete persistence
>>> abstraction, something I've always wanted to see. The ability to
>>> compare JPA, JDO and possibly other ORMs seems like a key feature
>>> right now. Having named and externalized queries is nice too.
>>>
>>> - Dave
Re: Let's pick an implementation (was Re: New roller persistence
implementation)
Posted by Elias Torres <el...@torrez.us>.
Allen,
I note a stark difference between this email and one of the first emails
from you in the thread:
"""
assuming we agree that we are only focusing on implementing one of the
options, we then need to decide which one. just so it's known, i think
it's entirely lame that we are getting rid of Hibernate over a silly
licensing issue. as a large roller customer i consider it more of a
pain than a benefit to have to replace the backend. regardless of that
fact, it appears that's what everyone wants to do, so i consider
Hibernate to no longer be an option. that leaves JDO and JPA as you
mentioned, and i don't really have any preference between the two. """
Now it seems that the *only* option for you (is it for Sun, too?) is
Hibernate. Is that correct? Why the change of opinion? If I may ask.
-Elias
Allen Gilliland wrote:
> I still want more information about the soft vs. hard dependency issue
> WRT Hibernate being part of the project, but whatever the outcome of
> that is doesn't change the fact that I continue to support Hibernate as
> our implementation.
>
> I should also say that depending on how this works out this is something
> that could put us (blogs.sun.com) at odds with the community and
> encourage us to go our own direction.
>
> My only concern is for my installation of Roller at blogs.sun.com and as
> I've said before, switching to something other than Hibernate is only
> going to create problems for us. As far as I'm concerned Hibernate
> still offers the best option as the persistence implementation and since
> the licensing issue does not affect us specifically then I don't see any
> reason to mess with it. At some point we will likely be willing to try
> a JPA implementation, but we are not really interested in being one of
> the first adopters, so that won't happen for a while.
>
> Depending on the outcome of the soft vs. hard dependency issue and
> whether or not apache will provide us some potential way to continue
> using Hibernate legally is what will determine my final point of view.
>
> -- Allen
>
>
> Dave Johnson wrote:
>> On 8/16/06, Anil Gangolli <an...@busybuddha.org> wrote:
>>> I support Elias's option #2 with some concessions to #1.
>>
>> I feel about the same way.
>>
>> On the question of "who here wants to replace Hibernate?"
>>
>> Hibernate's LGPL licensing is incompatible with Apache policy and
>> there exists a set of contributors who are willing and able to provide
>> an alternative backend impl. I'm a member of that set. If we create an
>> alternative, it works well and we've got consensus then we'll ship it
>> with Roller. Do we have to do this before we graduate? I sure as hell
>> hope not.
>>
>> On the question of "which ORM should we choose?"
>>
>> I definitely believe we should ship one ORM with Roller and the Roller
>> project should not do anything to promote, document or support the
>> idea of users plugging in alternative ORMs.
>>
>> Personally I favor JPA because 1) there will be multiple high-quality
>> implementatons (some at Apache) and 2) Hibernate is one of the
>> implementations. So we'd ship OpenJPA or something similar, but folks
>> who *really* want to continue using Hibernate can figure out on their
>> own how to configure Roller to use Hibernate's JPA implementation.
>>
>> On the question of "Data Mapper good or bad?"
>>
>> I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
>> ORM queries, just as our Persistence Strategy allows us to abstract
>> ORM load/save operations. We'll have a complete persistence
>> abstraction, something I've always wanted to see. The ability to
>> compare JPA, JDO and possibly other ORMs seems like a key feature
>> right now. Having named and externalized queries is nice too.
>>
>> - Dave
>
Re: Let's pick an implementation (was Re: New roller persistence
implementation)
Posted by Allen Gilliland <al...@sun.com>.
I still want more information about the soft vs. hard dependency issue
WRT Hibernate being part of the project, but whatever the outcome of
that is doesn't change the fact that I continue to support Hibernate as
our implementation.
I should also say that depending on how this works out this is something
that could put us (blogs.sun.com) at odds with the community and
encourage us to go our own direction.
My only concern is for my installation of Roller at blogs.sun.com and as
I've said before, switching to something other than Hibernate is only
going to create problems for us. As far as I'm concerned Hibernate
still offers the best option as the persistence implementation and since
the licensing issue does not affect us specifically then I don't see any
reason to mess with it. At some point we will likely be willing to try
a JPA implementation, but we are not really interested in being one of
the first adopters, so that won't happen for a while.
Depending on the outcome of the soft vs. hard dependency issue and
whether or not apache will provide us some potential way to continue
using Hibernate legally is what will determine my final point of view.
-- Allen
Dave Johnson wrote:
> On 8/16/06, Anil Gangolli <an...@busybuddha.org> wrote:
>> I support Elias's option #2 with some concessions to #1.
>
> I feel about the same way.
>
> On the question of "who here wants to replace Hibernate?"
>
> Hibernate's LGPL licensing is incompatible with Apache policy and
> there exists a set of contributors who are willing and able to provide
> an alternative backend impl. I'm a member of that set. If we create an
> alternative, it works well and we've got consensus then we'll ship it
> with Roller. Do we have to do this before we graduate? I sure as hell
> hope not.
>
> On the question of "which ORM should we choose?"
>
> I definitely believe we should ship one ORM with Roller and the Roller
> project should not do anything to promote, document or support the
> idea of users plugging in alternative ORMs.
>
> Personally I favor JPA because 1) there will be multiple high-quality
> implementatons (some at Apache) and 2) Hibernate is one of the
> implementations. So we'd ship OpenJPA or something similar, but folks
> who *really* want to continue using Hibernate can figure out on their
> own how to configure Roller to use Hibernate's JPA implementation.
>
> On the question of "Data Mapper good or bad?"
>
> I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
> ORM queries, just as our Persistence Strategy allows us to abstract
> ORM load/save operations. We'll have a complete persistence
> abstraction, something I've always wanted to see. The ability to
> compare JPA, JDO and possibly other ORMs seems like a key feature
> right now. Having named and externalized queries is nice too.
>
> - Dave
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by Dave Johnson <sn...@gmail.com>.
On 8/16/06, Anil Gangolli <an...@busybuddha.org> wrote:
> I support Elias's option #2 with some concessions to #1.
I feel about the same way.
On the question of "who here wants to replace Hibernate?"
Hibernate's LGPL licensing is incompatible with Apache policy and
there exists a set of contributors who are willing and able to provide
an alternative backend impl. I'm a member of that set. If we create an
alternative, it works well and we've got consensus then we'll ship it
with Roller. Do we have to do this before we graduate? I sure as hell
hope not.
On the question of "which ORM should we choose?"
I definitely believe we should ship one ORM with Roller and the Roller
project should not do anything to promote, document or support the
idea of users plugging in alternative ORMs.
Personally I favor JPA because 1) there will be multiple high-quality
implementatons (some at Apache) and 2) Hibernate is one of the
implementations. So we'd ship OpenJPA or something similar, but folks
who *really* want to continue using Hibernate can figure out on their
own how to configure Roller to use Hibernate's JPA implementation.
On the question of "Data Mapper good or bad?"
I'm +1 on Data Mapper. The Data Mapper pattern allows us to abstract
ORM queries, just as our Persistence Strategy allows us to abstract
ORM load/save operations. We'll have a complete persistence
abstraction, something I've always wanted to see. The ability to
compare JPA, JDO and possibly other ORMs seems like a key feature
right now. Having named and externalized queries is nice too.
- Dave
Re: Let's pick an implementation (was Re: New roller persistence implementation)
Posted by paksegu <pa...@yahoo.com>.
How about JPOX implementation of JDO?
Anil Gangolli <an...@busybuddha.org> wrote:
I support Elias's option #2 with some concessions to #1.
My strategy in similar situations would actually be to pick the
implementation and then code to its best-supported API.
Here's what I do support:
(a) Pick one and only one Apache-license-compatible ORM/persistence layer
*implementation* that we can distribute and whose use in Roller we will
support. It must be robust, reasonably efficient, and work over popular SQL
variants without us having to do a lot of our own work. (Hibernate has all
of these properties except ASF-license compatibility.)
(b) While it is definitely not a priority for me, I'm just fine with
architecting for
pluggability in order to help us switch later more easily if we need to.
However, I would only want to support the use of one API and in fact only
one implementation of that API in practice. If it happens that developers
can plug in something else at whatever level, they would be welcome to, but
they would basically be on their own. (Patches would be welcome along the
usual lines of course, but we wouldn't necessarily treat issues experienced
only on some alternate implementation as a bug.)
--a.
----- Original Message -----
From: "Elias Torres"
To:
Sent: Wednesday, August 16, 2006 5:42 AM
Subject: A forgotten option: iBatis (was Re: New roller persistence
implementation)
>
> I share some of the concerns that Jeff is bringing up in his mail and
> remember that long time ago Ted Husted had offered [1] to replace our
> Hibernate backend with iBatis or Cayenne. At the time, Dave said no
> thank you because Craig was working on JDO, but I hear mixed reviews on
> the work:
>
> 1. Some think that a pluggable strategy is good
> 2. Some would like to just pick one and move on
> 3. Some think is necessary just for license and we should always use
> hibernate
>
> We are fine with #1 and #2 not with #3. Therefore, I want to provide
> more support for #1 and #2 and suggest that if we have a pluggable
> strategy we could work on an iBatis implementation, maybe Ted will help
> us. If we choose #2, we would support an iBatis implementation. I think
> you get where I'm going. We are using iBatis internally in different
> projects and the experience has been good so far.
>
> I would love to hear your opinion on this.
>
> -Elias
Ransford Segu-Baffoe
paksegu@yahoo.com
paksegu@noqturnalmediasystems.com
http://www.noqturnalmediasystems.com/
http://www.noqturnalmediasystems.com/Serenade/
https://serenade.dev.java.net/
---------------------------------
Yahoo! Messenger with Voice. Make PC-to-Phone Calls to the US (and 30+ countries) for 2¢/min or less.