Shapira, Yoav wrote:
Hi,
A TOMCAT_5_0 branch was created at the time 5.0.27 was released. I'm
not gung-ho about making significant Tomcat 5.0 additions and
enhancements, given the advanced state of Tomcat 5.1 development. If
there's a showstopper, security, or spec-compliance bug than of course
it will be fixed and additional releases made.
I didn't know there was a branch already! Thanks - that's great.
As for the nature of the changes, the bug fixes are important fixes in the area of JSR 45 spec-compliance. I believe they affect all tools that use JSR 45 for debugging, not just NetBeans.
However, if you really want this strongly, feel free to submit patches
back-porting the CVS HEAD patches onto the TOMCAT_5_0 branch code, and
we'll look at them.
Thanks.
As for JDK 1.5 specifically: Tomcat 5.1 will support JDK 1.5 without
needing to modify anything. Tomcat 5.0 doesn't make that claim, but it
does let you modify parsers as you want using the standard endorsed
classloading mechanism. Of course I've already said that on the bug
report ;)
I guess there are two possible perceptions of this problem. One is that we should strive for the cleanest possible architecture, and have multiple releases each targetting a particular platform. The other is that there should be a single universal release that supports a range of platforms, and the architecture should be able to accomodate all of them. I prefer the latter approach, also because of the multi-user use case: if a single Tomcat installation (CATALINA_HOME) is used by multiple users (each having their own CATALINA_BASE), then the former approach does not work if each user has a different version of the JDK.
Hi,
Oh and BTW, definitely -1 on committing to regular monthly releases.
They'll come when they're ready: that's always been the process. And
"ready" itself is also ambiguously defined as a critical fix,
significant enhancements, large number of bug fixes, or a combination
thereof. If the average duration between releases for us has been 1
month, that's great, but it's a coincidence that I don't want to commit
to ;) There are far too many variables in our work for that.
Agreed, it is not reasonable to commit to regular release schedule (based on my own experience ;) In my mind, release schedule is an approximate guideline, not committment.
Yoav Shapira Millennium Research Informatics
Petr
goals-----Original Message----- From: Petr Jiricka [mailto:[EMAIL PROTECTED] Sent: Monday, August 09, 2004 12:43 PM To: [EMAIL PROTECTED] Subject: Tomcat 5.0.28 release
Hi,
we have been using Tomcat in the NetBeans product for about 4 years now (since the 3.2 beta releases), so first off, Thanks! for all your great work. Tomcat provides NetBeans users with the ability to run their applications out of the box, debug in on the Java and JSP level, and generally serves as an excellent testing environment for web applications developed using NetBeans.
Now, on behalf of the Sun Developer Tools group, I'd like to propose a
next release of the Tomcat 5.0.x codeline, i.e. Tomcat 5.0.28. The
model.of this release would be the following:
- Continue to deliver a stable release of Tomcat in roughly 1 month
intervals. One of the reasons why Tomcat is so highly valued in the
community is because the time between finding a bug and deliveing the
fix is very short, thanks to the short release cycles. The community
appreciates the high quality of releases resulting from this release
necessary- The Sun Developer Tools group would like to include into this release several bug fixes in the Jasper area, that are currently available in the trunk (5.1.x codebase), and that affect NetBeans 4.0 functionality, such as JSP debugging or JSP editor.
- The goal of 5.0.28 would be to support the upcoming JDK 1.5 release
(now called JDK 5.0) out of the box, so no post-install setup steps are
necessary to run on JDK 5.0. Note that in Tomcat 5.0.27, it is
to manually remove file common/endorsed/xml-apis.jar to make Tomcatwork
with JDK 5.0, see also bug report 29579 or Tomcat release notes. Thisproblems
not only degrades the initial experience on 1.5, but also poses
5.0.xin the multiuser scenario, when some of the users who use a shared Tomcat installation run JDK 1.4.x, and others run 1.5. (Implementation-wise, this could be done e.g. by ignoring xml-apis.jar in the classloader, when running on JDK 5.0, but there may be other solutions available.)
- Last but not least, other bug fixes present in the trunk, that are easily and safely portable to 5.0.x, should be considered.
From a codeline perspective, we are suggesting to create a Tomcat
branch (exact name TBD) off the Tomcat 5.0.27 tag, and continue the 5.0.x development in this branch. Also, subsequent releases of Tomcat 5.0.x beyond 5.0.28 can be considered, until the 5.1 codebase reaches stability, or while there is interest in the community to continue development of the 5.0.x codebase.
Thanks in advance for your comments.
Petr Jiricka Sun Developer Tools group
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
