> From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
>
> Leo Sutic wrote:
> >
> >>From: Berin Loritsch [mailto:[EMAIL PROTECTED]]
> >>
> >>Leo Sutic wrote:
> >>
> >>>In theory, if a container is 100% A4 compliant, it should
> >>
> >>remain so for
> >>
> >>>all future
> >>>versions of A4, in the same way that a component, once
> >>
> >>having achieved
> >>
> >>>100% A4 status,
> >>>will remain so until A5.
> >>
> >>
> >>ECM has been made A4.1 compliant. A4.1 is *released*.
> >
> >
> > I'm fully aware of that. But my point is that instead of
> having just
> > Avalon 4, we have Avalon 4.0, Avalon 4.1, and we'll have Avalon 4.2,
> > and the frameworks will be sufficiently different that a container
> > written
> > for Avalon 4.0 will not be completely Avalon 4.1 compliant.
> >
> > That's fine, if you can committ resources to playing
> catch-up with an
> > evolving standard, but the whole point of a framework is that you
> > should not *have* to play catch-up.
>
> If the container is upgraded to be 4.1 compliant, you can
> still use your legacy code. Is that a problem? That way the
> user does not have to play catch-up. They can do it a little
> bit at a time.
>
> > Now I'm all for evolving specifications, but it is a fact that the
> > framework that claims to be most fundamental for everything
> (i.e. you
> > would use Avalon to build an EJB server), is also the
> framework that
> > has changed
> > the most, and that has consumed most of my catch-up resources.
>
> Really. You think Avalon Framework has changed *that* much?
> If I am not mistaken, EJB specs have changed a bit
> too--probably more so than Avalon 4.x.
The difference is that Avalon is the only framework where a user
is expected to write a container.
EJB specs may change, but the only one that needs to play catch-up
is the EJB container developer, not the bean developer.
> > That is my problem and not yours - but to dismiss the
> problem with a
> > "A4.1 is *released*" is just not right. It assumes that
> once the gods
> > at avalon-dev releases a new version, the rest of the world
> had better
> > keep up or they will, can and should be left behind.
>
> No my point is that because Avalon 4.1 is released we need to
> support it.
OK, misunderstood you.
> > As long as Cocoon promises to run on JDK1.2, we have to support it.
>
> Oh, I see. However, you're the only one from Cocoon
> complaining. In fact, quite a few of the Cocooner's are in
> favor of upgrading their minimum JDK standard--and they need
> a good reason to do it. We solved their problem for them.
I don't mind going to 1.3. But Cocoon has promised to be 1.2
compliant. Remove that promise and we're fine. But until that
is done, I think we at Avalon-land has some responsibilities
to not switch JDK versions.
I'm complaining pre-emptively.
I don't want us to switch VM version, and only then realize that
"Oops, didn't anyone change the sys reqs. to be JVM 1.3+ ?"
It would not look good.
/LS
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
