From dev-return-64163-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org Tue Aug 10 16:06:42 2004 Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 29669 invoked from network); 10 Aug 2004 16:06:42 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 10 Aug 2004 16:06:42 -0000 Received: (qmail 61988 invoked by uid 500); 10 Aug 2004 16:06:22 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 61907 invoked by uid 500); 10 Aug 2004 16:06:22 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 61894 invoked by uid 99); 10 Aug 2004 16:06:22 -0000 X-ASF-Spam-Status: No, hits=-2.8 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [209.237.227.194] (HELO minotaur.apache.org) (209.237.227.194) by apache.org (qpsmtpd/0.27.1) with ESMTP; Tue, 10 Aug 2004 09:06:20 -0700 Date: Tue, 10 Aug 2004 09:06:19 -0700 (PDT) From: "Adam R. B. Jack" To: dev@cocoon.apache.org Subject: RE: Cocoon and JCS (on Gump) (fwd) Message-ID: <20040810090352.W23802@minotaur.apache.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Hi, It seems the JCS folks are (now) thinking of preparing a release. Given this will be their first release, and this change will be in the release, does it seem prudent for Cocoon to track this change now, and get as much testing time as possible? regards Adam -- Have you Gump'ed your code today? http://gump.apache.org ---------- Forwarded message ---------- Date: Tue, 10 Aug 2004 08:51:42 -0700 From: "Smuts, Aaron" Reply-To: Turbine JCS Developers List To: Turbine JCS Developers List Subject: RE: Cocoon and JCS (on Gump) Yes. We can release. All the known bug fixes and the improvements that we wanted to get done first have been completed. I need to find out the process. Aaron -----Original Message----- From: Estefano Eduardo [mailto:eduardo.estefano@siemens.com] Sent: Tuesday, August 10, 2004 2:13 AM To: Turbine JCS Developers List Subject: RE: Cocoon and JCS (on Gump) I think the problem is that there are no releases of JCS yet, so this is not possible. If you update your cvs repository you may be getting stuff that will break your working code. Isn't JCS stable enough for a Beta version release? This way other applications could know what what they are getting into through the release notes, change logs, etc. -----Original Message----- From: Adam R. B. Jack [mailto:ajack@apache.org] Sent: Monday, 09 August, 2004 23:01 To: Turbine JCS Developers List Cc: dev@cocoon.apache.org Subject: RE: Cocoon and JCS (on Gump) On Mon, 9 Aug 2004, Travis Savo wrote: > According to the change log Aaron Smuts made this change on 6/28/2004 > in order to make .dispose() visible to the clients of the JCS class. > > I expect it will be a permanent change because it's reasonable that > clients of the JCS class will want to dispose of a region themselves. > > The only problems I foresee with upgrading this in the field is if > there's a class that extends CacheAccess (which you appear to be > doing). In this case you will need to upgrade your code, but I expect > this to be an isolated and rare occurrence. Assuming that's not the > case, I see no problems mixing jars in the field in relationship to > this change. > > Does that answer your question? First, thanks for the answer. Second, API changes happen (fact of life), and Gump (and my questions) are just trying to see if we can mitigate against issues in the field, be early detection and discussion/etc. Frankly, my low level java is insufficient to know if subtleties of access contraints (on a method) make it into the signature, and/or otherwith affect runtime. I could imagine that such a change annoys compilers, but slides through at runtime (in many case). I don't think there is an easy way for anybody to allow a transition path, given this type of change. As such, I suspect the correct approach is to note it, and try to move on. BTW: What would really help is notice of what releases the old 'signature' is in, and what release the new one might be in. Having this be in the RELEASE NOTES could help also. Could you answer that question, and try to remember it for the CHANGES notification. BTW: I'll CC the cocoon community on this one, to see if they are comfortable changing their code. Thanks for your help. regards Adam --------------------------------------------------------------------- To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: turbine-jcs-dev-unsubscribe@jakarta.apache.org For additional commands, e-mail: turbine-jcs-dev-help@jakarta.apache.org