Yes, it is a common problem when using third party libraries.
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.
Let's take Velocity example. We could also create own template engine. I will be small, simple, no version conflicts. But if everybody is going to create everything he need development will be slow, not reusable, time expensive.
One more disadvantage that since you have developed something accessory for your main project that is working, you are don't have time to evolve it (or even not interested in it). So it's frozen (no optimization no performance growing). Usually you will change it in only one case: some critical bug.
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.
Also it's our fault that we are using so old Velocity version. Cayenne SQL Template rendering can be faster and stable with new version.
Evgeny.
-----Original Message-----
From: Andrus Adamchik [mailto:andru..bjectstyle.org]
Sent: Thursday, December 31, 2009 1:53 PM
To: de..ayenne.apache.org
Subject: Re: [jira] Commented: (CAY-1300) Format queries in QueryLogger
On Dec 31, 2009, at 12:38 PM, Evgeny Ryabitskiy (JIRA) wrote:
> To be honest I am still not sure that developing new container is
> better then using already created and well tested (for years) like
> Spring. Yes it's bigger but 300 kbs isn't so critical for huge
> application (my wars are 30 mbs)... at least not used classes are
> not loading to memory.
This is good point, and in fact we did evaluate this route. A benefit
of our own container that outweighed everything else was that it is
the most unassuming option. There will never be a conflict with the
user application using a different version of Spring, etc. The fewer
dependencies we have, the more self-containing cayenne-server.jar is,
the easier it is for the end users to include Cayenne in their various
environments (J2SE, JEE, OSGi, etc.) and various application stacks.
Even Cayenne 3.0 has too many dependencies to my liking. E.g. we are
on Velocity 1.3, and the Velocity project is at 1.6.2 now. Apache
Click uses Velocity for template rendering. So Click/Cayenne users
will need to choose a single version of Velocity and pray that it
works for both Cayenne and Click. So I sorta wanted to avoid this
situation with DI.
Andrus
This archive was generated by hypermail 2.0.0 : Thu Dec 31 2009 - 06:43:46 EST