You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Clinton Begin <cl...@gmail.com> on 2009/01/26 23:49:39 UTC
[RESULT] Should iBATIS support SQLJ?
The vote to officially accept the contribution of SQLJ support to the
core iBATIS source base has failed.
* A quick count count of all votes (unofficial, but conclusive;
binding and non-binding) yields:
- 5 votes for,
- 5 votes impartial, and
- 10 votes against.
* Two votes in favor can be counted from the contributors.
* All binding votes were against.
It is clear that the community does not show a great deal of support
for SQLJ, nor do the committers, thus iBATIS will not officially
support SQLJ. iBATIS 2.x development has stabilized to maintenance
only. Thus we do not expect further major changes or features to be
introduced, as development of iBATIS 3.0 nears Alpha stage.
We welcome the contributors to either find a way to add this support
without modifying the iBATIS source code, or by forking the source and
maintaining their own parallel release.
Best regards,
Clinton Begin
On Fri, Jan 23, 2009 at 12:05 PM, Clinton Begin <cl...@gmail.com> wrote:
> Hi everyone,
>
> A group of developers have approached us with a contribution of code
> to patch iBATIS so that it supports SQLJ.
>
> If you've never heard of SQLJ, here are two links...
>
> http://en.wikipedia.org/wiki/SQLJ
> http://www.google.com/trends?q=sqlj
>
> The future of SQLJ is not clear to me, nor is its adoption rate over
> time. Certainly iBATIS has a broader user base than SQLJ does.
>
> So the question is: Should we support SQLJ as a feature of iBATIS?
>
> +5 == Absolutely... iBATIS will be better for it.
> +1 == Yes, support SQLJ.
> 0 == Doesn't matter to me.
> -1 == No, keep them separate.
> -5 == No way. iBATIS is better off without it.
>
> This vote will remain open for 72 hours.
>
> Cheers,
> Clinton
>
Re: [RESULT] Should iBATIS support SQLJ?
Posted by Mario Ds Briggs <ma...@in.ibm.com>.
thanks clinton. Graciously accepted.
>>
We welcome the contributors to either find a way to add this support
without modifying the iBATIS source code.
<<
Assumed following Jeff's suggestion, a simple 'Executor' registration
mechanism is acceptable.
thanks
Mario
Clinton Begin
<clinton.begin@gm
ail.com> To
iBatis Java Mail List
27/01/2009 04:19 <us...@ibatis.apache.org>
cc
Please respond to Subject
user-java@ibatis. [RESULT] Should iBATIS support
apache.org SQLJ?
The vote to officially accept the contribution of SQLJ support to the
core iBATIS source base has failed.
* A quick count count of all votes (unofficial, but conclusive;
binding and non-binding) yields:
- 5 votes for,
- 5 votes impartial, and
- 10 votes against.
* Two votes in favor can be counted from the contributors.
* All binding votes were against.
It is clear that the community does not show a great deal of support
for SQLJ, nor do the committers, thus iBATIS will not officially
support SQLJ. iBATIS 2.x development has stabilized to maintenance
only. Thus we do not expect further major changes or features to be
introduced, as development of iBATIS 3.0 nears Alpha stage.
We welcome the contributors to either find a way to add this support
without modifying the iBATIS source code, or by forking the source and
maintaining their own parallel release.
Best regards,
Clinton Begin
On Fri, Jan 23, 2009 at 12:05 PM, Clinton Begin <cl...@gmail.com>
wrote:
> Hi everyone,
>
> A group of developers have approached us with a contribution of code
> to patch iBATIS so that it supports SQLJ.
>
> If you've never heard of SQLJ, here are two links...
>
> http://en.wikipedia.org/wiki/SQLJ
> http://www.google.com/trends?q=sqlj
>
> The future of SQLJ is not clear to me, nor is its adoption rate over
> time. Certainly iBATIS has a broader user base than SQLJ does.
>
> So the question is: Should we support SQLJ as a feature of iBATIS?
>
> +5 == Absolutely... iBATIS will be better for it.
> +1 == Yes, support SQLJ.
> 0 == Doesn't matter to me.
> -1 == No, keep them separate.
> -5 == No way. iBATIS is better off without it.
>
> This vote will remain open for 72 hours.
>
> Cheers,
> Clinton
>