I am in complete agreement with Clinton on this one. There has to be measured caution when going "common". The term is a bit misleading because not everyone uses the same version of the "common" component. It then is not so common anymore. I've also realized that when i do use a commons component it is only a small portion of it and really does not justify a full jar dependency. Most of what the common components address are usually pretty narrow and could easily be handled within a project without much ado. On the java side I will say we need to remain free of dependencies and will avoid using commons components. But, on the .NET side I can see it being more flexible. However, the GAC does not sound like a good place to manage this. Perhaps i'm wrong...but isn't that like putting stuff into the ext file of your jre? Also, I recently sat through a week long course on the finer points of .NET. C# and ASP.NET. It was a very informative course. But, i can say that i wasn't really impressed with the library versioning. I thought it would be more provocative. It seems to me that it is overcomplicated and may induce more frustration that ease of use in the long run. But, that very well could be my complete lack of experience talking.
Brandon On 5/27/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. > > > >
