cayenne-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Рябицкий Евгений <>
Subject RE: [jira] Commented: (CAY-1300) Format queries in QueryLogger
Date Thu, 31 Dec 2009 11:43:01 GMT
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.


-----Original Message-----
From: Andrus Adamchik [] 
Sent: Thursday, December 31, 2009 1:53 PM
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.


View raw message