Return-Path: Delivered-To: apmail-ibatis-user-java-archive@www.apache.org Received: (qmail 14498 invoked from network); 8 Apr 2010 02:37:52 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 8 Apr 2010 02:37:52 -0000 Received: (qmail 64328 invoked by uid 500); 8 Apr 2010 02:37:51 -0000 Delivered-To: apmail-ibatis-user-java-archive@ibatis.apache.org Received: (qmail 64297 invoked by uid 500); 8 Apr 2010 02:37:51 -0000 Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user-java@ibatis.apache.org Delivered-To: mailing list user-java@ibatis.apache.org Received: (qmail 64274 invoked by uid 99); 8 Apr 2010 02:37:51 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Apr 2010 02:37:51 +0000 X-ASF-Spam-Status: No, hits=2.9 required=10.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [209.85.221.201] (HELO mail-qy0-f201.google.com) (209.85.221.201) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Apr 2010 02:37:42 +0000 Received: by qyk39 with SMTP id 39so493512qyk.24 for ; Wed, 07 Apr 2010 19:37:20 -0700 (PDT) Received: by 10.229.224.149 with SMTP id io21mr5725598qcb.64.1270694239757; Wed, 07 Apr 2010 19:37:19 -0700 (PDT) Received: from [192.168.1.100] (206-248-171-209.dsl.teksavvy.com [206.248.171.209]) by mx.google.com with ESMTPS id 23sm9031794qyk.3.2010.04.07.19.37.17 (version=SSLv3 cipher=RC4-MD5); Wed, 07 Apr 2010 19:37:18 -0700 (PDT) Message-ID: <4BBD4154.6030500@bbs.darktech.org> Date: Wed, 07 Apr 2010 22:37:08 -0400 From: cowwoc User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b1 Thunderbird/3.0.4 MIME-Version: 1.0 To: user-java@ibatis.apache.org Subject: Re: SqlSession.close() without committing References: <4BBC0BF3.5050109@bbs.darktech.org> <4BBCAA6B.5050406@bbs.darktech.org> <07094E40F055C34FA35BB28DB1670E7F0127EBDA@bibbmail.bibb.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070006060605020500050909" X-Virus-Checked: Checked by ClamAV on apache.org --------------070006060605020500050909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Clinton and Rick, I do not think that iBatis is a business, nor am I attempting to make demands as to how you should run your project. I've learned a long time ago that no amount of pressure will work with open-source projects. Good projects are few and far between so I appreciate what you've done here. In my experience, the best ones are actively maintained, well documented and have a strong community backing. I believe quite strongly that good documentation should consist of *both* manuals and Javadoc. To that end, I am more than willing to contribute bug reports and Javadoc patches. Simply point me in the right direction ;) Keep up the good work! Gili On 07/04/2010 2:48 PM, Clinton Begin wrote: > Martin, > > I appreciate your point, but Rick's is valid to. > > Sometimes it's easy to get the general feeling that people think > iBATIS or the ASF is a business, and they expect our project to work > for them. > > However, this is not a business. I don't make any money from iBATIS > (as in ZERO). I've contributed my time for free for over 8 years > now. The framework does what it does. I do what I can do. And I > prioritize based on what I want to do -- which can be influenced, but > not controlled, by the opinions of the community. > > It's a hobby for me. I use my own framework. The prioritization of > what gets done is largely driven by popular community vote, bug > criticality and my own needs (as with any other committer who is > entitled to prioritize their own features by their own needs -- > responsibly). > > If there were a way to commercialize it, I would be more than happy to > write docs for other people, write specs for other people, implement > features for other people, and even make a lot of improvements and > enhancements that I know are possible -- for other people. > Unfortunately the practicality of commercialization disappeared the > moment I contributed iBATIS to the Apache Software Foundation. > > Therefore the best we can do is based on our own time available. > > Anyone interested in contributing is welcome to join. I recommend > reading carefully about the Apache Software Foundation first... > > http://www.apache.org/foundation/how-it-works.html > > Then I recommend you file an ICLA with the Apache Software Foundation > -- after you carefully read and understand it. > > http://www.apache.org/licenses/icla.txt > > Then start building your merit through responsible contributions to > the framework. > > Otherwise, file a Jira ticket, try to get community support and > encourage the existing team to support your needs. > > Cheers, > Clinton > > > > On Wed, Apr 7, 2010 at 11:34 AM, Martin Ellis > wrote: > > Rick, > > I don't think making facetious comments is likely to help, > particularly when talking about people who already submit patches, and > submit feedback on betas. > > Martin > > > On 7 April 2010 17:46, Rick.Wellman > wrote: > > Hey Clinton, > > You've got volunteers coming out of the woodwork ;-) > > > > -----Original Message----- > > From: Martin Ellis [mailto:ellis.m.a@gmail.com > ] > > Sent: Wednesday, April 07, 2010 11:43 AM > > To: user-java@ibatis.apache.org > > Subject: Re: SqlSession.close() without committing > > > > One thing I'd have liked to see is an indicator of which > packages are > > intended as API packages for public consumption, and which packages > > are implementation. > > > > The idea being that I'd like to minimise dependencies on > 'private' API. > > There're a few incentives to do that: > > > > * making sure you're using a well-trodden code paths - they tend > to be > > well tested; > > * reducing the likelihood of having to rework code when upgrading to > > later versions; > > * ensuring you're not caught out if iBATIS ever gets an OSGI > > MANIFEST.MF, which prevents importing private packages. > > > > For example, right now I have a dependency on BoundSql - and I've no > > idea whether that's likely to be maintained as part of a stable API. > > > > I don't share the cynicism about Javadoc - I can think of plenty of > > libraries outside the JDK with useful Javadoc. For example, the > > Apache Commons javadocs tend to be very good, describe corner-cases > > like null-handling, and have class javadocs that show useful > examples. > > > > I've been completely baffled by how MetaClass, MetaObject, > > ObjectFactory and ObjectWrapper and ObjectWrapperFactory are > related, > > and what they're used for. I don't know whether they're all > > considered public API, but I've had to trace through them tracking > > down bugs. > > > > Martin > > > > > > On 7 April 2010 16:53, cowwoc > wrote: > >> Clinton, > >> > >> I'm not looking for a specification in that sense of the > word :) I meant > >> something along the lines of Design by Contract: > >> http://en.wikipedia.org/wiki/Design_by_contract > >> > >> If my code depends on iBatis and upgrading to a newer > version breaks my > >> code then how do we establish whether the problem is: > >> > >> 1. The iBatis implementation no longer conforms to its > specification (i.e. > >> an iBatis bug) > >> 2. My code assumed something about an iBatis method that was > not guaranteed > >> by the specification (i.e. a bug in my application) > >> > >> Thanks, > >> Gili > >> > >> On 07/04/2010 9:50 AM, Clinton Begin wrote: > >> > >> Then you might be happier with a spec like JPA. Although I'd > warn that such > >> specs are rarely implemented consistently. > >> > >> This is what has killed J2EE vs. the alternatives. Look at the > history: > >> > >> * CMP - Spec. Dead, along with all implementations. > >> > >> * EJB - Spec. Dead. Spring killed it -- not a spec. > >> > >> * JDO - Spec. Dead, along with all implementations. > >> > >> * JSF - DOA. Bad idea to begin with, and has failed to unify > client side > >> Java. Struts, GWT, Wickett, Stripes, ZK, Tapestry, etc. all > still exist -- > >> and are more popular than JSF -- all without a spec. > >> > >> Some specs have succeeded, due to their simplicity and natural > interface > >> boundary (usually a network connection requiring a driver of > sorts). These > >> include Servlet, JDBC and JMS. Even though they're not the > nicest, they're > >> simple and necessary. Yet they too differ in many ways, > especially JDBC. > >> JPA has a chance, but only because they essentially took the > two most > >> popular frameworks that weren't specs and made them into a > spec... nobody > >> will be winning any innovation awards for that one. > >> > >> The spec doesn't guarantee anything. Kind of like a green > light doesn't > >> guarantee that cars won't be driving through the opposing red > light at an > >> intersection... do you not check? > >> > >> The only thing that defines how a framework will work is the > framework > >> itself -- spec or not. The only protection you have is your > own unit, > >> functional and integration tests -- which you need anyway, as > it's also the > >> only way you'll know if YOUR code works. > >> > >> We've created a user guide to describe the intended behavior of > the iBATIS > >> framework. If it is somehow incomplete or incorrect, you can > contribute to > >> it via the wiki discussed on page 2. > >> > >> Clinton > >> > >> > >> > >> On Tue, Apr 6, 2010 at 10:37 PM, cowwoc > > wrote: > >>>> > >>>> Yes, iBATIS will rollback the connection if it deems it > necessary. The > >>>> only > >>>> time you might need to call rollback explicitly is if you > have a "select" > >>>> that actually updates data in the database. Such is > sometimes the case > >>>> with > >>>> stored procedures. > >>>> > >>> > >>> Clinton, > >>> > >>> Coming back to our earlier discussion of Javadoc... where do > you document > >>> the iBatis specification? I hope you understand my reluctance > of depending > >>> on behavior outside of an explicit specification. Today one > person will tell > >>> me the method works one way, tomorrow another person will tell > me a > >>> different story. I'd love to have an official document to > refer back to. > >>> > >>> Thanks, > >>> Gili > >>> > >>> > --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: > user-java-unsubscribe@ibatis.apache.org > > >>> For additional commands, e-mail: > user-java-help@ibatis.apache.org > > >>> > >> > >> > >> > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org > > > For additional commands, e-mail: > user-java-help@ibatis.apache.org > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org > > For additional commands, e-mail: user-java-help@ibatis.apache.org > > > --------------070006060605020500050909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Clinton and Rick,

    I do not think that iBatis is a business, nor am I attempting to make demands as to how you should run your project. I've learned a long time ago that no amount of pressure will work with open-source projects. Good projects are few and far between so I appreciate what you've done here. In my experience, the best ones are actively maintained, well documented and have a strong community backing.

    I believe quite strongly that good documentation should consist of *both* manuals and Javadoc. To that end, I am more than willing to contribute bug reports and Javadoc patches. Simply point me in the right direction ;)

Keep up the good work!
Gili

On 07/04/2010 2:48 PM, Clinton Begin wrote:
Martin,

I appreciate your point, but Rick's is valid to.

Sometimes it's easy to get the general feeling that people think iBATIS or the ASF is a business, and they expect our project to work for them. 

However, this is not a business.  I don't make any money from iBATIS (as in ZERO).  I've contributed my time for free for over 8 years now.  The framework does what it does.  I do what I can do.   And I prioritize based on what I want to do -- which can be influenced, but not controlled, by the opinions of the community.

It's a hobby for me.  I use my own framework.  The prioritization of what gets done is largely driven by popular community vote, bug criticality and my own needs (as with any other committer who is entitled to prioritize their own features by their own needs -- responsibly).

If there were a way to commercialize it, I would be more than happy to write docs for other people, write specs for other people, implement features for other people, and even make a lot of improvements and enhancements that I know are possible -- for other people.  Unfortunately the practicality of commercialization disappeared the moment I contributed iBATIS to the Apache Software Foundation.

Therefore the best we can do is based on our own time available.

Anyone interested in contributing is welcome to join.  I recommend reading carefully about the Apache Software Foundation first...

http://www.apache.org/foundation/how-it-works.html

Then I recommend you file an ICLA with the Apache Software Foundation -- after you carefully read and understand it.

http://www.apache.org/licenses/icla.txt

Then start building your merit through responsible contributions to the framework.

Otherwise, file a Jira ticket, try to get community support and encourage the existing team to support your needs.

Cheers,
Clinton



On Wed, Apr 7, 2010 at 11:34 AM, Martin Ellis <ellis.m.a@gmail.com> wrote:
Rick,

I don't think making facetious comments is likely to help,
particularly when talking about people who already submit patches, and
submit feedback on betas.

Martin


On 7 April 2010 17:46, Rick.Wellman <Rick.Wellman@kiewit.com> wrote:
> Hey Clinton,
> You've got volunteers coming out of the woodwork ;-)
>
> -----Original Message-----
> From: Martin Ellis [mailto:ellis.m.a@gmail.com]
> Sent: Wednesday, April 07, 2010 11:43 AM
> To: user-java@ibatis.apache.org
> Subject: Re: SqlSession.close() without committing
>
> One thing I'd have liked to see is an indicator of which packages are
> intended as API packages for public consumption, and which packages
> are implementation.
>
> The idea being that I'd like to minimise dependencies on 'private' API.
> There're a few incentives to do that:
>
> * making sure you're using a well-trodden code paths - they tend to be
> well tested;
> * reducing the likelihood of having to rework code when upgrading to
> later versions;
> * ensuring you're not caught out if iBATIS ever gets an OSGI
> MANIFEST.MF, which prevents importing private packages.
>
> For example, right now I have a dependency on BoundSql - and I've no
> idea whether that's likely to be maintained as part of a stable API.
>
> I don't share the cynicism about Javadoc - I can think of plenty of
> libraries outside the JDK with useful Javadoc.  For example, the
> Apache Commons javadocs tend to be very good, describe corner-cases
> like null-handling, and have class javadocs that show useful examples.
>
> I've been completely baffled by how MetaClass, MetaObject,
> ObjectFactory and ObjectWrapper and ObjectWrapperFactory are related,
> and what they're used for.  I don't know whether they're all
> considered public API, but I've had to trace through them tracking
> down bugs.
>
> Martin
>
>
> On 7 April 2010 16:53, cowwoc <cowwoc@bbs.darktech.org> wrote:
>> Clinton,
>>
>>     I'm not looking for a specification in that sense of the word :) I meant
>> something along the lines of Design by Contract:
>> http://en.wikipedia.org/wiki/Design_by_contract
>>
>>     If my code depends on iBatis and upgrading to a newer version breaks my
>> code then how do we establish whether the problem is:
>>
>> 1. The iBatis implementation no longer conforms to its specification (i.e.
>> an iBatis bug)
>> 2. My code assumed something about an iBatis method that was not guaranteed
>> by the specification (i.e. a bug in my application)
>>
>> Thanks,
>> Gili
>>
>> On 07/04/2010 9:50 AM, Clinton Begin wrote:
>>
>> Then you might be happier with a spec like JPA.  Although I'd warn that such
>> specs are rarely implemented consistently.
>>
>> This is what has killed J2EE vs. the alternatives.  Look at the history:
>>
>> * CMP - Spec.  Dead, along with all implementations.
>>
>> * EJB - Spec.  Dead.  Spring killed it -- not a spec.
>>
>> * JDO - Spec.  Dead, along with all implementations.
>>
>> * JSF - DOA.  Bad idea to begin with, and has failed to unify client side
>> Java.  Struts, GWT, Wickett, Stripes, ZK, Tapestry, etc.  all still exist --
>> and are more popular than JSF -- all without a spec.
>>
>> Some specs have succeeded, due to their simplicity and natural interface
>> boundary (usually a network connection requiring a driver of sorts).  These
>> include Servlet, JDBC and JMS.  Even though they're not the nicest, they're
>> simple and necessary. Yet they too differ in many ways, especially JDBC.
>> JPA has a chance, but only because they essentially took the two most
>> popular frameworks that weren't specs and made them into a spec... nobody
>> will be winning any innovation awards for that one.
>>
>> The spec doesn't guarantee anything.  Kind of like a green light doesn't
>> guarantee that cars won't be driving through the opposing red light at an
>> intersection... do you not check?
>>
>> The only thing that defines how a framework will work is the framework
>> itself -- spec or not.  The only protection you have is your own unit,
>> functional and integration tests -- which you need anyway, as it's also the
>> only way you'll know if YOUR code works.
>>
>> We've created a user guide to describe the intended behavior of the iBATIS
>> framework.  If it is somehow incomplete or incorrect, you can contribute to
>> it via the wiki discussed on page 2.
>>
>> Clinton
>>
>>
>>
>> On Tue, Apr 6, 2010 at 10:37 PM, cowwoc <cowwoc@bbs.darktech.org> wrote:
>>>>
>>>> Yes, iBATIS will rollback the connection if it deems it necessary.  The
>>>> only
>>>> time you might need to call rollback explicitly is if you have a "select"
>>>> that actually updates data in the database.  Such is sometimes the case
>>>> with
>>>> stored procedures.
>>>>
>>>
>>> Clinton,
>>>
>>> Coming back to our earlier discussion of Javadoc... where do you document
>>> the iBatis specification? I hope you understand my reluctance of depending
>>> on behavior outside of an explicit specification. Today one person will tell
>>> me the method works one way, tomorrow another person will tell me a
>>> different story. I'd love to have an official document to refer back to.
>>>
>>> Thanks,
>>> Gili
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>>> For additional commands, e-mail: user-java-help@ibatis.apache.org
>>>
>>
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
For additional commands, e-mail: user-java-help@ibatis.apache.org



--------------070006060605020500050909--