On Tue, 2007-07-31 at 14:59 -0400, Yoav Shapira wrote: > > It's all done in Ant tasks: look for how > the Tomcat build handles Jakarta Commons DBCP for example.
I absolutely despise how that is built. It makes building that jar a complete NIGHTMARE. Presently we do not offer than jar on Gentoo and I have no plans to. Or worse potential ways to. Because I will have to hack around our packaging system to even make an attempt. Hard coding versions of a libraries sources within another package, and not as a package dependency. But as additional sources for Tomcat :(. Despite a newer version of those libraries already existing on the system. Which also means they have downloaded a copy of that packages sources, but might not have installed the sources. It is the oldest bug wrt to Tomcat on Gentoo :( http://bugs.gentoo.org/buglist.cgi?quicksearch=tomcat It came up in the past here, where others also disliked the process of how it was built. But so far has fallen on deaf ears. I have not had the time or chance to address the issue and provide you all with a code work around. http://marc.info/?l=tomcat-dev&m=115808287528288&w=2 > We don't > trim them down AFAIK, nor do we have to do any porting because we > re-grab the library (ideally from a known stable version) with every > release. I see there are some slight modifications. Other than the re-branding and re-packaging. Which at the end of the day I really fail to see the benefit to this approach. Verses just shipping collections, pool, and dbcp. Not to mention many drivers have their own factories. But recently as a user discovered. This is not a valid work around for Global resources. As that is hard coded no matter what is configured in server.xml to use tomcat-dbcp.jar. -- William L. Thomson Jr. Gentoo/Java
signature.asc
Description: This is a digitally signed message part
