On Dec 31, 2009, at 1:43 PM, ςΡΒΙΓΛΙΚ εΧΗΕΞΙΚ wrote:
> But I think the right solution is to every time evaluate new
> versions of used libraries and it's compatibility with Cayenne.
> And if it possible - migrate to new versions (never lag behind
> life). I know it is also a huge work but it's better.
>
> [...]
>
> Instead third party project is been developing for long time. Lot's
> of optimization/bug fixes (even before we find them) is provided in
> new versions which can be easily catch by our project.
>
> Actually that is why I am using Cayenne instead of creating some own
> solution.
This is all good, but consider the difference between developing an
application and developing a framework. In the former case, you ship a
black-box .war or .jar to the end user. Users couldn't care less
what's inside, as long as it has familiar UI. The later case is more
nuanced, and third-party dependency issue can't just be dismissed or
dealt with by upgrading to the latest version of everything. (For
completeness, there's a third group of developers well represented at
Apache - container developers, who are allowed to get loose with deps).
When we started on Cayenne back in 2001-2002, we'd use every single
utility lib out there to make our life easier. We shipped a bunch of
odd dependencies like commons-beanutils (cause we didn't want to
implement our own reflection), etc. It wasn't a disaster or anything,
but every now and then an issue would pop up in one environment or
another (e.g. most application servers used to include the entire
Apache commons-* zoo creating weirdest class loader issues, and still
do actually).
So my design preference (as a framework designer) has shifted from
"import any third-party lib we find remotely useful" to "import
nothing; if you absolutely have to introduce a dependency, make it
optional and pluggable". Cache management is a good example. We don't
want to re-implement OSCache or EHCache in Cayenne, still we don't
want Cayenne tied to any of those. Instead we allow the users to plug
them dynamically. Velocity is probably the only remaining piece that
is not easily abstracted out.
With DI we got somewhat lucky that it turned out much simpler to write
than I expected, so we don't have a write a "Spring plugin", "Guice
plugin", "Tapestry5 Plugin" (we may still run into issues when we
start using it actively, but till now it was a cakewalk). So after
that discovery it was a no brainer.
Anyways, just trying to explain why we did what we did.
> Also it's our fault that we are using so old Velocity version.
Maybe, but then there will be at least one other library out there
that depends on older Velocity. Either way we are putting burden on
the user to figure it out, instead of just telling him - drop cayenne-
server.jar in your app and you are done.
Andrus
This archive was generated by hypermail 2.0.0 : Thu Dec 31 2009 - 10:06:37 EST