OK, I tried abator this weekend to see what it was like - it seems to be generating alot of traffic, which got me wondering what I was missing.
So, I downloaded and unzipped it (no eclipse for me, thanks), and tweaked out a config file for a project I am working on and ran it on a couple of tables. It ran OK, so I popped open the code to see what I had. I am not sure how to say this, and I do not mean to be discouraging, but I was shocked to see so much code. Like not in a good way - 7,777 lines of code and xml in 10 files for 2 medium sized tables. Extrapolating that out to a system with 50-60 tables put me in the 200,000 - 250,000 line range. If I were an iBATIS beginner, it would have been so intimidating that I'd have moved on to another tool like hibernate or db-commons without a second look at iBATIS. With that in mind, I re-evaluated the mail that has been coming about it, and got started thinking about it. Obviously, people are using it, so it's not all bad, I just think we can find a better solution. While I think that Abator does address a problem with iBATIS (i.e. creating simple sql by hand sucks), it is not a tool I'd recommend or use in it's current state for a couple of reasons. First is the sheer amount of code it creates - 200,000 lines for 50 tables is unmanageable. Second is the amount of duplication in the generated code - the dao implementation was 3,000 lines long, and nearly all repetitive. Jeff, I hope you don't read this and take it personally or get discouraged by it, I think you are fun guy to have on the team, and a very practical problem-solver (both great traits in a developer). I just brought this up, because I want everyone to look at it as it grows, and make sure that it matures into something that fits with the philosophy of iBATIS, and improves the framework. Larry
