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
