03.03.07
Posted in Uncategorized at 1:26 am by skoobi
I happened to read this blog entry about NOT reinventing the wheel. I 100% agree with the author. However, I would like to add something important : Reinventing the wheel is bad, but integrating too much stuff together will necessarily cause headaches about version incompatibilities, subtle problems, etc..
For instance… Let’s say you want to display AJAX-pages that will query the server asynchronously for some stuff, and display the result to the user. One of the best alternatives is DWR, so let’s say you use version 2, because it supports annotations, etc..
Now, you want to create AJAX-validation of your forms. You don’t want to reinvent the wheel, so you use something like Struts2, with the ajax theme. Bad luck ! Struts2 seems to work fine with DWR1, but one will have problems with DWR2… How do you solve the issue ? Patching, patching, patching, if you have the time.
The problem is that this kind of headaches constantly happens whenever you use a few frameworks and libraries, which completly kills the productivity… Another real headache would be the use of Spring 2 + AspectJ + Hibernate to Dependency-inject POJOs… The problem + solution is described on this post…
Another example I came accross would be the incompatibility between some prior ActiveMQ version (before 4.x was released) and Spring 2.0, whereas everything was working fine in 2.0 RC4… The problem came from Xbean 2.6 which was incompatible with Spring 2.0 final….
And I could post hundreds of framework-headaches … I am not saying frameworks and libraries are bad (otherwise, I wouldn’t use them), but they’re not paradise either…
Permalink
Posted in Uncategorized at 1:08 am by skoobi
I came accross this blog entry which is a mini “howto install maven2 under debian”. Thanks for the hint, and thanks to the Debian Java team for working on official Debian packages for maven2.
However, I think we have a deeper problem than just the lack of maven2 package.. Just take a look at the number of jars in Maven2 repository. And this doesn’t take into consideration the jars offered on Java.net repository, or Apache Incubating one.
So, what is the problem exactly ? Well, it is going to be IMPOSSIBLE for Debian to keep up with the crazy and constantly increasing amount of Java jars available. So, instead of trying to re-package Java libraries once again (mainstream developers already have to package them for maven1 and maven2), why not work on some integration between Debian Packages and Maven2 ones ? And when you think a bit about it, Debian has the same problem with PHP PEAR and and Perl CPAN.
Maven2 is a full-blown java package system that expresses dependencies, etc. So, to my opinion, what Debian should do is the following :
- Create a notion of a “soft-depencency”. Basically, this would mean that any Package can have hard dependencies (the current deb dependencies), and soft dependencies which could be resolved by a soft-dependency subsystem.
- In order to deal with Java, CPAN and PEAR’s case, a soft-dependency could be expressed as prefix:dependency. A soft-dependency manager could register a prefix, and the dependency string would be subsystem-specific. So, for instance, if I need freemarker, the dependency could be maven2:freemarker/freemarker/2.3.8
Now, the question is whether Debian is ready to accept such a shift in its concept ?
Permalink