On Sat, 2002-09-28 at 15:26, Leo Sutic wrote: > > From: Berin Loritsch [mailto:[EMAIL PROTECTED]] <snip> > > As a result, if Cocoon wants to use the latest and greatest > > ECM, then it must use JDK 1.3 or higher. I am sure that JDK > > 1.3 will help make some things easier to do in Cocoon. Also > > note that should Cocoon use the latest and greatest from > > Fortress (comming to a store near you RSN) or Merlin, it > > would have to upgrade to JDK 1.3 or better anyway. > > While I'm sure the change is for the better, if anyone has > deployed Cocoon an a JDK1.2.2 system, this effectively makes > them out of luck when it comes to Cocoon bugfixes etc. > > Cocoon 2.0 has been out for a year, and I think it is a severe > violation of contracts to suddely say that "sorry, you need > JDK 1.3" when Cocoon so far has maintained JDK1.2 compatibility. > > See http://xml.apache.org/cocoon/installing/index.html: > > Apache Cocoon requires the following systems to be already > installed in your system: > > Java Virtual Machine A Java 1.2 or later compatible virtual > machine must be present for both command line and servlet > type usage of Apache Cocoon. Note that all servlet engines > require a JVM to run so if you are already using servlets you > already have one installed. > > I bet people have made business decisions based on that information. > > Somehow this contract must be maintained, at the very least for > the 2.0 branch. > > + Avalon 4 contains the ComponentManager interface and thus > *all* component that claim to be Avalon 4 compatible MUST > support the Component interface.
-1 on defining "avalon compatible component" this way. The whole point of service.* is that you can have "avalon compatible components" that do not implement Component! > Yes, it is deprecated, but > unless you intend to roll out A5, Component et al. are there > to stay and *must* be supported. my personal stance is that avalon framework, the avalon containers etc should support Component & friends. I however don't feel that all avalon components must do the same (it can be made a container concern to handle the pain, it has been made a container concern, and I like that...) That said, I can't really see why it would be a problem to have all components the ECM depends on extend Component. > Solution: Let Monitor implement > Component again. That would make it A4 compliant. Then there's > no need for the proxy generator for Cocoon. if at all possible I would like to see a solution where the container handles the 'legacy support'. I am not any kind of bytecode/rmi wizard though so I am not sure that is feasible. I have no problem at all with Monitor implementing Component though. > + Maintain 2 versions of ECM - one 1.2 without the proxy and one 1.3+ > with it. ieeuw! If that's what it takes, that's what it takes though. > Finally, Avalon makes ***no*** promises that I could find on the > webpages about what JDK it will run / compile on. So I think the > promise made by the Cocoon team of supporting JDK1.2 is a bit > impossible, and that it should be qualified to be for the 2.0 branch > only or something. seems like it. I sure never test against 1.2. However, a promise made is a promise made and if it is relatively easy (IIUC all we need to do is implement Component for the various components in excalibur CVS) for us to help Cocoon keep that promise I'm all for it. Especially since the alternative (code fork) sounds like it will be painful. > (Avalon team: Do we promise anything in regard to JVM versions?) generally, I (and others) complain very loudly when some stuff stops working on 1.3. Other people do the same for 1.4. We have no formal rules/promises across-project, and I think it should stay that way. (There can be good reasons for hosting a jdk1.4-only component in avalon cvs, or even (especially) a jdk1.5-only). I do feel it would be good to clearly specify supported JVM versions for different (sub)subprojects. Just some opinions =) cheers, Leo -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
