Most companies or developers end up writing their own lightweight DAO layers. In those cases they are going to have to distribute their custom DAO API anyways. In the case of Ibatis DAO, you are using a premade DAO layer so you will be sharing that API. In either case, you will have a DAO layer that will have some dependencies. You will have to distribute youre DAO API whether you write your own DAO or use iBatis DAO (which is different from iBatis SQL Mapper).
<quote>Well, ideally, you'd like to have your interfaces be unconcerned with how the thing is actually implemented behind the scenes.</quote>
That's the point of having a DAO layer - whether its IBatis DAO or something you write on your own, you are abstracting the actual persistence implementation. Perhaps you are getting the IBatis DAO confused with the IBatis SQL Mapper.
<quote>Now, you've introduced a dependency on the iBatis Dao interface which requires us to have the iBatis jar in the client's classpath, when the client could care less that we're using iBatis behind the scenes on the server.</quote>
The IBatis is just the DAO layer -- you would some sort of DAO implementation at that level whether you use IBatis or roll your own. So I don't see what your point is.
The benefit to using IBatis DAO is that you have access to a pretty robust implementation that allows you to swap in different persistence implementations behind the scene. It's all about code reuse wherever possible, at least for me. And IBatis has alot of advantages in that area. Why rewrite a DAO layer everytime you start a new project at a different company or contract.