On Mon, 25 Mar 2002, Kin-Man Chung wrote:

> I have been doing it so far in my own sandbox.  The reason for this is not
> to keep it a secret, but to avoid de-stablizing the current tomcat,
> since a lot of my early work was mainly experimental.  There have
> been interests recently in making the new Jasper public, so I am going to
> do that, even though it is not ready to replace the current jasper yet.

Don't worry about de-stabilizing tomcat - as long as the old code is still 
around and usable you can't destabilize too much. Coyote development is a 
good example.

> My plan is to create a new jasper directory (jasper2) under jakarta-tomcat-4.0,
> and to modify build.xml to allow for building jasper from sources under either
> jasper(the default) or jasper2 (the new jasper).  This arrangement allows
> both the existing jasper and the new jasper to coexist and be co-developed
> without affecting each other.  One drawback is that some files are duplicated
> in both directories and bugs fixed in one need to be duplicated in the other.
> But hopefully such an arranagement is only temporary and when the new jasper
> is in good enough shape, it will replace the existing one.

I would sugest using the jakarta-tomcat-jasper repository. This way the 
new jasper can be used with both tomcat 4.0 and 4.1 ( and even 3.3, if 
the 1.2 features can be disabled by a flag - I assume it would be easy to 
walk the tree and detect if any 1.2 feature has been used, and report an 
error ), and the development will be much cleanly separated.

There is already an experimental refactoring for jasper in that CVS, which 
can be eventually removed ( if the tag recycling is merged with your 
version of jasper ).

Costin


--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to