On Monday, 9 בJanuary 2006 21:34, Boris Unckel wrote: > > But then, if the API library calls a 3rd party library, that > > library can't be put in WEB-INF/lib either - it has to be put in > > the tomcat's startup classpath as well. > > Ok. I will repeat to ensure I understand it: > You have a development system where you do not want to jar for each > test of your API, you also do not want to war (ant task) before you > test. Your API depends on 3rd party JARs which are not in the default > distribution of Tomcat.
Yes, more or less. The problem is not a single locally developed library - the problem is that I have many of those, and each required different third party libraries. > For your development system only (please do not use this on a > production machine): > Put your classes in > TOMCAT_ROOT/shared/classes > (create the folder if not existing) As mentioned above, I have more then one project that requires this treatment - putting the products of all projects in one place is not the way I want to go, as its a mess and it will be hard to know which class belongs to which project, and I may also encounter name conflicts (I don't believe that I have those, but its not guaranteed). > put your libs in > TOMCAT_ROOT/shared/lib I'm trying to avoid the need to put the 3rd party dependencies of all the web applications in a single place - due to the reasons you noted. An optimal setup for me, I think, is: - for each application to put the 3rd party dependencies in WEB-INF/lib (I'm using JPackage's build-jar-repository, which I auto invoke from the ant script, so its even automatic). - for each application that users locally developed libraries to list their build directories in the web.xml so what the WebAppClassLoader can get at them without them being shared. This kind of setup would leave all the mess out of the JVM classpath, would allow me to define on a per web application what I want it to have on the classpath by once editing a simple file, and won't require me to do complex hand-eye coordination routines each time new code is introduced. My current interim solution (which is bad) is to have the continuous build process for each locally developed library also create the jar packages, and then I symbolically link them into the WEB-INF/lib directory. The main down side is that this lengthens the continuous build process by almost twice as much, and so a lot of times I have to wait for eclipse to finish a source code commit (that blocks the user interface) before I can continue to work. -- Oded ::.. I've never been canoeing before, but I imagine there must be just a few simple heuristics you have to remember... Yes, don't fall out, and don't hit rocks. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
