On 14.08.2006 22:19, Daniel Fagerstrom wrote:
And as your veto is based on among other things servlet container
compatibility we need to know if there are containers that we find it
important to support for 2.2 that doesn't work with Java 5.
As I already said: servlet containers have not been my argument! I only
added a comment to your first answer.
but servlet spec does not matter that deeply IMO. I voted +1 on
servlet 2.4 mostly because of the request listeners. As long as the
2.4 features are kept out of core (which of them can surface
coincidentally?) we still can claim 2.3 compatibility and provide 2.4
features like request listeners as optional features. The same way
Spring is handling the request/session scoped beans by providing a
listener [1] (see Javadoc) and a filter [2].
The servlet API has always been a central part of Cocoon and with 2.2 it
becomes even more important as it is used instead of the Processor
interface.
Of course.
To follow what you say above means in practice that core
parts of Cocoon must not use 2.4 and that 2.4 can only be used in
optional blocks that no important functionality should depend on. The
vote about Servlet 2.4 was about using Servlet 2.4 in trunk. If you want
to achieve what you describe above you must veto that proposal and make
an alternative proposal.
The above walk just talking in large. In the meantime I had a look into
the 2.4 spec what actually changed since 2.3. And indeed besides minor
refinements (IMO unimportant to Cocoon) it's only the request listener
that's new. And even if Cocoon uses these features and does not provide
alternatives I can live with it as it is only a small amount of code
that would be needed to be implemented in case somebody needs really
2.3. That's why I support the change to 2.4. The impact is very low. A
bigger change in the API would probably have not gotten my approval as
well ...
Besides this I don't really see how it is related to Java 5.
OK. So that bring us back to the key question: what specific problem
would we get by using Java 5?
So our policy for updating libraries is far for what you require for
updating JDK. Also, not updating JDK will give us increasing problems in
using the latest stable version of used libraries as they are starting
to require Java 5.
I don't care that much about that point. There are not many libraries
actually requiring Java 5. And besides that those might provide Java 1.4
compatible releases as well.
For the "killer features", lots of people have said that they are
interested in using various features in Java 5, do you find your lack of
interest in these features a strong enough reason to prevent others from
using them?
Missing interest is for sure not my reason to veto the change.
(This is getting me too personal here ... please don't imply such
ignorance.)
The core offering from the Spring framework is the bean factory, which
is a low level framework that is used in numerous other projects many of
which are used by still other projects in turn. Cocoon is a much higher
level framework, and is with a few exceptions used directly to build
applications with. This means that it is enough to ask our users what
they think, while Spring need to understand their users users. And
because of that need to be more conservative.
So, Cocoon and Spring are quite different kind of beasts, so we need to
understand why they support Java 1.3 to know if their reasons are
relevant for us.
I absolutely can't agree. Both are just application frameworks - with
Cocoon being more web-tied.
Isn't this quite easy? Always provide a Java 1.4 alternative and make
Java 5 features optional. See declarative transaction demarcation in
Spring. It's completely possible without Java 5. But you can use
annotations for it as well. And even those can be used with Java 1.4
and commons attributes IIRC.
Always providing a 1.4 alternative means a lot of extra, and fairly
boring, work. I think we better focus on one version.
Might be. That was just my proposal instead of switching to Java 5.
I simply still can't see how Java 5 will help us significantly.
And if you keep your veto you will prevent all the rest of us who
believe that it would help us to explore if it will help us as well.
No, no. Please stay serious. There are other playgrounds to explore Java
5. It must not be Cocoon.
But this far no one have said that they would have any problems with
it, neither at cocoon-dev or cocoon-user.
This remains my main point though: losing some of our user base. You may
never have been working for a bank, but there such changes in the
requirements take years til they get applied. When we wrote an
application based on Mozilla 1.0 the customer still used Netscape 4.0.x,
not even the latest available version of Netscape at that time, which
was 4.7.x IIRC. We fought for weeks until it was allowed to get Mozilla
1.0 installed on their desktop computers. Andrew's mail from half an
hour ago seems to affirm this.
Besides that such customers/users are often not active in the open
source community. We all (at least visitors of Cocoon GT from 2 (?)
years ago) know a famous example, where we could not even publish the
name of a big company using Cocoon. Or the company I work for: We use
many different open source libs. But I don't think there was much
response to the community. And I still have to do bug fixes at home as I
could not give back patches or code I did at work due to copyright
reasons. You might just not have the majority of our user based involved
here.
I still stand with my -1 vote. I don't want to be attacked personally
for it. Sorry for it, but we don't agree here.
Regards,
Jörg
