July 17, 2006
Problems with open source versioning
This is showing up more and more. We see various bit of code using open source libraries like commons-* but more and more we're seeing versioning conflicts where component X uses V2.1 but a newer component thats supposed to run with X requires V3.0 and we can't just put V3 on top of X because of support issues, X won't retest and support V3.0 at this point in time so then you're in a rock and a hard place.
Major hassle. I can see a commons monolithic spec aggregating the jars as one level and then components prereqing version X of that spec. Sounds too much like J2EE, no?
I think as open source builds useful components and makes them better and products start picking up these components, this is going to be a pretty big problem. I guess JSRs pushing this function in to J2SE is one option but then innovation slows down and you can't get the latest level without a new JDK version.
Solutions like OGSI could help but who wants 4 versions of an open source component loaded simultaenously with 4 class loaders? It's possible but that doesn't mean you want to do it.
Anyway, no easy answer in sight for now.
July 17, 2006 | Permalink
It seems you just started to use open source stuff lately. The issue you describing started to show up some time ago and several projects have tried to attack it from various angles. Maven 2, Ivy and even Sun's JSR-277 has some take on it. The key point is to collect and maintain all the module metadata and know exactly what the dependency are, so it will be possible to build a toolset that could help to resolve conflicting dependencies.
Posted by: Eugene Kuleshov | Jul 17, 2006 12:13:05 PM
Been using it for a while but usually we update it in the latest revision of the application server and everybody is on the same page.
My problem is different in that I have the ObjectGrid and I want it to run on multiple levels of the application server with the same jar files. Different levels of the application server have different levels of these jars. The APIs have changed over these levels and this causes problems of course.
Same thing would apply if someone used ObjectGrid with Spring, or any other open source library. They are slowly prereqing the entire OS universe and this means using them together will get interesting.
Posted by: Billy | Jul 17, 2006 3:29:53 PM
Hehe, the problem is Websphere. Users of WebSphere have been having the same issue for ages. Having multiple classloaders is part of the architecture of J2EE, but for some reason, WebSphere wants to be "helpful" and provide a whole bunch of libraries for free. The problem is, they are generally ancient versions, and I want to run with something vaguely up to date.
for instance see:
http://jira.atlassian.com/browse/JRA-7699 (language warning :-)
Posted by: Jed Wesley-Smith | Jul 17, 2006 8:22:37 PM
I always find comments like "it's websphere" amusing, and remind me of the time a consultant, trying to get his app to work, rather than solve the problem (database concurrency), made the suggestion to managers to use some other (now defunct) app server.
Fact is, Java, and in turn WebSphere, have a rather sophisticated and complex classloader so it's easy to get lost here. At the simplest level, you need to carefully test your apps, and manage all upgrades - requiring specific jars, not allowing Joe developer to throw out version-x-super-duper of Spring or whatnot, thus breaking other functionality.
In a more sophisticated way, and I think in the Atlassian link above, they figured out a simple solution, which is to put more effort into your project to make it compatible. I can think of two projects, where great effort is being done in this are: java.util.concurrent, in which there is a backport for version 1.4. As an interesting aside, in this DeveloperWorks article co-authored by Billy Newport, notice that you can use various versions of the Oswego, backport, and java.util thread pool implementation, on various versions of WebSphere, up to the point that WAS 6 supports all 3 versions. Nice.
The second example is JUnit 4.0, which provides forward *and* backward compatibility. This required a significant amount of their development time, but obviously with a tool which is widely considered to be the most useful and widely used open source utility out there, it's a requirement.
Posted by: Robert Jones | Aug 14, 2006 4:42:00 PM