I also agree with Clinton. When you began to mixed several framework you tend to have version conflict even in .NET world, the best exemple is for the DataMapper and the NHibernate support, we have migrate
iBATIS.NET to Castle.DynamicProxy V1.1.0.0 and the they use V1.0.4 which is source of conflict.
On 5/28/05, Clinton Begin <[EMAIL PROTECTED]> wrote:
I suppose it's time I share a very important iBATIS principle with everyone....
Since version 2.0 , iBATIS has maintained a minimal set of dependencies ... one in fact. The only dependency iBATIS has is commons logging, and recently there's been talk of even removing that.
Being the only person who ever maintained iBATIS version 1.0, I can share my personal horror stories with you from my own experience, as well as the experience of our users. Dependencies, even internal ones cause problems for frameworks that are at a level as low as ibatis. We have to be considerate of our user community, as well as be good neighbours to other layers of the application. For example, if we want to use commons beanutils, logging, lang and collections, we will be in potential version conflict with Struts (for example). Furthermore, I've had bad experiences with other dependencies such as JDOM, which WebSphere uses internally, which was in conflict with the version of JDOM that iBATIS used. That was an especially frustrating case, because iBATIS used the latest version, but WebSphere used an old beta. But who are we, when pitted against WebSphere? Certainly a potential iBATIS user isn't going to ditch the Application Server they paid $16,000 for, in favour of our open source framework. There is possibility this could happen with other dependencies too, especially as more Apache projects gain popularity.
More importantly though, is if our users want to use a new version of commons!
In a sense, this is Java's "DLL hell". It's unfortunate, but true. This is an area that .NET can no doubt manage a bit better, but even that is at the mercy of the implementors, to ensure that versions are properly managed (potentially in the GAC).
iBATIS for Java metrics...
Java files = 238
Lines of Code = 15036
Avg LOC = 63.2
Shortest file = 3 lines
Longest file = 702 lines
iBATIS for Java Common...
Java files = 31
Lines of Code = 3144
Avg LOC = 101.4
Shortest file = 5 lines
Longest file = 702 lines
The common package accounts for about 18% of our code, and changes the least. I don't think that's unmanagable from our perspective. Even if we could reduce the codebase by removing commons, I beleive that managing various versions of 3rd party or even Apache dependencies would be worse (even if we originally created it!).
I'm personally always interested in making iBATIS smaller, simpler and free of depenencies. I'd like to see the Java version down to one JAR. I don't even like some of the optional dependencies! :-)
In any case, I hope you understand where I'm coming from and appreciate this warning from my own past experience.
Cheers,
Clinton
On 5/27/05, Ted Husted <[EMAIL PROTECTED] > wrote:On 5/27/05, Ron Grabowski < [EMAIL PROTECTED]> wrote:
> I came across this today:
> http://www.gotdotnet.com/Workspaces/Workspace.aspx?id=e5546f13-1ced-47d1-8667-53b613cc4873
>
> It has a DotNet.Commons.Reflection namespace that contains similiar
> functionality found in IBatisNet.Common .
If there are namespaces or packages in either iBATIS implementation
that we could share with other projects, then, by all means, we should
consider setting up shop in the Jakarta Commons sandbox, and float a
proposal.
No one's done this for a C# namespace yet, but there's been talk, and
no one seems very much opposed. It's just a matter of someone wanting
to do it.
I've got a working port of the Commons Chain of Responsiblity here:
* http://svn.apache.org/viewcvs.cgi/struts/sandbox/trunk/overdrive/Agility
It's stable, and I'm tempted to move it from the Struts Sandbox to the
Jakarta Commons Sandbox, but I don't know if anyone else is interested
in using it right now.
-Ted.
