cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <>
Subject RE: Cocoon and JCS (on Gump) (fwd)
Date Tue, 10 Aug 2004 16:06:19 GMT

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?


Have you Gump'ed your code today?

---------- 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.


-----Original Message-----
From: Estefano Eduardo []
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 []
Sent: Monday, 09 August, 2004 23:01
To: Turbine JCS Developers List
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

BTW: I'll CC the cocoon community on this one, to see if they are
comfortable changing their code.

Thanks for your help.



To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message