ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From cowwoc <cow...@bbs.darktech.org>
Subject Re: SqlSession.close() without committing
Date Thu, 08 Apr 2010 02:37:08 GMT
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 
> <mailto: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
>     <mailto: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
>     <mailto:ellis.m.a@gmail.com>]
>     > Sent: Wednesday, April 07, 2010 11:43 AM
>     > To: user-java@ibatis.apache.org <mailto: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
>     <mailto: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 <mailto: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
>     <mailto:user-java-unsubscribe@ibatis.apache.org>
>     >>> For additional commands, e-mail:
>     user-java-help@ibatis.apache.org
>     <mailto:user-java-help@ibatis.apache.org>
>     >>>
>     >>
>     >>
>     >>
>     >
>     >
>     ---------------------------------------------------------------------
>     > To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>     <mailto:user-java-unsubscribe@ibatis.apache.org>
>     > For additional commands, e-mail:
>     user-java-help@ibatis.apache.org
>     <mailto:user-java-help@ibatis.apache.org>
>     >
>     >
>
>     ---------------------------------------------------------------------
>     To unsubscribe, e-mail: user-java-unsubscribe@ibatis.apache.org
>     <mailto:user-java-unsubscribe@ibatis.apache.org>
>     For additional commands, e-mail: user-java-help@ibatis.apache.org
>     <mailto:user-java-help@ibatis.apache.org>
>
>


Mime
View raw message