ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Clinton Begin <clinton.be...@gmail.com>
Subject [RESULT] Should iBATIS support SQLJ?
Date Mon, 26 Jan 2009 22:49:39 GMT
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 <clinton.begin@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

View raw message