>As some of you may have noticed, Tomcat 4 is starting to depend on some >modules from the J-T-C repository. The problem is that it >creates in some >cases some circular dependencies for some build options. The >number of the >dependencies is also expected to go up in the future, >including: JK, the new >Java HTTP/1.1 connector, the util package, and the webapp connector. > >There are 3 solutions that we can use: >- Duplicate the code. Given the amount of code, I'm -1 with >that solution. >- Integrate building these components into the Tomcat 4 build process. >That's probably the most elegant solution, but unfortunately >it's tricky to >pull that off (and I tried ...). >- Put the JARs for these modules in the Tomcat 4 CVS (the lib directory >looks like a good candidate for this), based on stable (and tagged or >branched) versions of each component. > >I would choose the 3rd solution, since it is simpler, while >getting the job >done.
I'll be for solution #2 / #3 Let me make a small recall to new readers. I've battled many months to have the J-T-C sub-project. The original goal was to have a connector stuff independant from Tomcats at least Tomcat 3.3 and 4.0. An important point is that J-T-C contains more native code than java code and could (should) have a higher release rate. I plan to do a release of J-T-C, jk part, just after TC 3.3 will be released and that we'll have backported java change from TC 3.3 to ajp13 java code in tomcat33 and tomcat4 dirs. We should mimic the http/apr teams and have tagged versions from which you could grab known jars (ajp.jar and tomcat-util.jar) into TC 4.0. I think we will do the same for TC 3.3