Does that project look like http://www.ibatis.com/ clone? Could anyone write short comparison?
They say imitation is the highest form of flattery. Well, I for one am flattered (can't speak for the rest of our team). ;-)
Nils has done some nice work with ObjectBroker. The best thing about it is the support for more class designs without having to follow the beans spec. This is something that is important to the iBATIS team as well. We've definitely seen an increase in the number of people abandoning the JavaBeans specification for more flexibility in their class designs. It is for this reason that iBATIS will soon support constructor and field based mappings.
That said, kudos to Nils for making this a priority in his framework.
This flexibility does come at a cost though. The O/R Broker XML file is complex and heavily nested. Granted, O/R broker supports constructors, custom setter methods, fields and properties....all of this flexibility does come at the cost of the complex mapping file. However, I can't believe that it had to be this complex. For example:
<result-object id="Employee" class="my.package.Employee">
Some might argue that this example doesn't use a good class design (which probably makes it a good example). Sometimes we don't have a choice, in which case, O/R broker is awesome for supporting this. However, given a choice, I'd probably not want Salary and Currency as peer properties of my Employee class. A better design IMHO would be Salary of type "Money" on my employee class. Money is responsible for supporting the currency value. With such a class design, and using iBATIS, this mapping would look like this:
<resultMap id="Employee" class="my.package.Employee">
<result property="id" column="EmployeeId"/>
<result property="name" column="Name"/>
<result property="salary.value" column="Salary"/>
<result property="salary.currency" column="Currency"/>
<result property="SSN" column="SSN"/>
* of course, salary would be better as an immutable class with constructor value and currency params.
Or, with iBATIS and a mapping this simple, you don't need this stanza at all. This statement will automatically map the properties without a separately defined result map.
<select id="getEmployee" resultClass="my.package.Employee" parameterClass="int">
SELECT EmployeeId as id,
Salary as "salary.value",
Currency as "currency.value",
EmployeeId = #id#
In addition, iBATIS does support quite a few other features not supported by O/R broker. Those that immediately come to mind are:
* Join mapping of M:N relationships (N+1 selects solution)
* Optimized dynamic SQL 
* Pluggable Cache models
* Custom type handlers
* SQL fragments
* Pluggable transaction managers (think WebSphere)
* XML parameters and results
* Map parameters and results
* Support for arrays
* Lazy loading of ANY complex type
* Type aliases
* Automatic result and parameter mapping
 Although O/R broker supports Velocity and Freemarker, the resulting dynamic conditionals and iteration will not be much better than typical Java code. It simply moves the same amount of logic and introduces a 3rd language. iBATIS uses optimized XML tags to allow you to _reduce_ the amount of logic required to implement a dynamic SQL statement.
Then of course there are the non-technical reasons:
* Three years worth of production use
* A very large user community
* A growing team of 6 committers
* An active, production quality .NET version
Finally, I just want to mention a few corrections from the comparison found at the website:
* Resolves circular references - iBATIS solves circular references the same way O/R broker does...with a cache. But yes, you do have to configure the cache in iBATIS for this to work.
* Supports declarative and programmatic transaction isolation levels - iBATIS has supported this for the last two versions (at least).
* Supports inheritance mapping - This has been in the .NET version since day one, and was added to the Java version in 2.1.0.
When all is said and done, I think Nils did a great job on O/R Broker. I hope this message helped to describe some of the key differences. We always welcome newcomers to he SQL Mapping space, there's lots of room!
Awesome job Nils!