In my non-committer-therefore-not-really-relevant-opinion, EscapeUtils.escapeJavaScript() is a useful method, and it's reasonable to debate whether that is a good reason for a dependency; but EqualsBuilder and HashCodeBuilder are massively lame, and adding a dependency on commons-lang to get *them* is too much.
Dependencies are bad. Duplicate code is bad. The habit of Apache Commons changing APIs from one version to another is bad. Etc. There's no clear answer, but avoiding dependencies except where obviously necessary is a good start. BTW, John Fallows has a young baby (Jack) at home these days, which is a pretty good reason for him to be kind of in absentia. :) -- Adam On 10/19/05, Simon Kitching <[EMAIL PROTECTED]> wrote: > Werner Punz wrote: > > > The main problem I see is if there is some kind of version interface > > break, you > > could end up with two different incompatible versions. > > How do the commons people handle that. > > I recently had a very similar situation, I ended up giving the > > commons-http with all its dependencies (including commons lang) its own > > namespace and left as only dependency commons-logging, because given > > my experiences, those interfaces are very stable. > > > > Do the commons people have a common criteria for this when to brake > > major interfaces if at all? > > > > > > But MyFaces is rather harmless in its dependencies, the worst cases > > probably I have encountered in libs you have to use constantly are > > probably Hibernate and all which comes along the jboss embedded line. > > They almost drag half of the commons libraries with them and a bunch of > > other stuff like JTA. > > Spring is rather unintrusive in their dependency use. > > > > And given the popularity of Hibernate, this could be really an issue > > in the long run, once some of the commons core libs breaks something. > > > > While commons lang is pretty save it is always something you have to > > have in mind. > > > > > > Hi All, > > The problems with dependencies on external libs are: > > "Global" dependency issue: > ========================== > MyFaces has a dependency on commons-lang 2.1 (needs the > StringEscapeUtils class). If someone wants to combine it with a library > that has a dependency on commons-lang 1.x then they are stuffed; there > is *no* easy solution for that when using java. Actually, although there > *are* some binary incompatibilities between 1.x and 2.x it's only > limited to a few classes. So it's *probably* possible to use 2.x with a > lib that declares a dependency on 1.x. However it's almost impossible > for an end developer to know whether that combo will work or not. > > And the reverse can be true too; if commons-lang 3.x comes out, and > someone wants to use it, how can they know whether MyFaces works with it > or not? > > Support issue: > ============== > > When some functionality of MyFaces depends on the behaviour of an > external library, then MyFaces behaviour can vary depending upon what > lib versions someone has in their classpath. So when someone files a bug > saying that "my page using jscookmenu is reporting a javascript error" > it isn't enough to know what version of MyFaces they have; you need to > know that commons-lang is a dependency of jscookmenu, then advise them > to check what version of commons-lang is in their classpath. And these > days with so many jars floating around in container classpaths that > isn't always easy to determine. > > Basically, MyFaces behaviour will vary by user environment. Users can be > running many different combinations - which have never been explicitly > tested together. > > However if the code is inside MyFaces, then behaviour is predictable: > when someone has myfaces version x.y.z then the behaviour is completely > known. > > Bugs in external libs: > ====================== > > If there is a bug in an external lib that affects MyFaces you need to > submit a bug request, wait until it is fixed then notify all MyFaces > users that they need to upgrade that external lib (with potential > knock-on effects to the other dependencies in their projects). If the > code is internal to MyFaces you just fix it. > > > > Of course I'm not suggesting that every dependency be copied. It's a > tradeoff. However the StringEscapeUtils is fairly stable: > * jun 27 2005 made mod that isn't relevant to MyFaces > * jun 26 2005 added feature (not a problem for MyFaces) > * sep 13 2003 syntax cleanup only > * jul 31 2003 - change that might be relevant to MyFaces > > http://svn.apache.org/viewcvs.cgi/jakarta/commons/proper/lang/trunk/src/java/org/apache/commons/lang/StringEscapeUtils.java?rev=234019&view=log > > Concern has been expressed that "each release we must merge changes from > the commons-lang project" but I don't think that is the case. As long as > the implementation in MyFaces is working nothing needs to be done. > > > Basically, dependencies on external libs are a two-edged sword. You get > bugfixes for free that way, but you also get undesired behavioural > changes for free. > > > Anyway, I'm not really too bothered about this issue personally; I just > noticed it because code that ran fine with myfaces 1.1.0 now throws an > exception with 1.1.1RC3 because I never had commons-lang in the > classpath and now HtmlCalendar needs it. But the blame probably lies on > me for failing to read the official dependency list for MyFaces. > > I'm going to shut up about this now, and let you all get on with the > good work you're doing :-) > > Cheers, > > Simon >
