On 10.08.2006 11:41, Daniel Fagerstrom wrote:
As Java 5 was released almost 2 years ago, I propose making it the
minimum requirement for trunk and all artifacts released from there.
-0, because this means eliminating cocoon 2.2 on "older" application
servers eg weblogic 8.1.
IIUC weblogic 8.1 uses servlet 2.3 so I guess you need to veto the use
of servlet 2.4 to make this a valid point.
Don't know about Weblogic (it was not my argument), 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].
If there are other use cases that require Java 1.4 you should seriously
consider if Simones proposal of using the Retroweaver would be enough.
This works only as long as you don't use extensions made to the JDK
classes. Different JDK versions are not just about language features but
also about APIs. So this is no replacement IMO.
Frankly, I don't see the point in upgrading unless there's a killer
feature in 1.5 that
1) we are likely to use and implement in the near future (2006) and,
2) will improve cocoon by a significant margin.
We never require something like that when we update the version on
libraries we depend on. For libraries we depend on the latest stable
version as long as it doesn't create any problems, we never require that
anybody is going to use the latest features.
Don't understand that point.
I second this, but vote even -1. I wonder why a framework should set
such high requirements. Have a look on spring. They have a Java 1.3 as
minimum requirement and only need Java 5 for special features.
IMO we should do it in a similar manner and not set the general
requirement to Java 5.
Cocoon is both a framework and a set of applications. Compared to
Spring, Cocoon is less framework oriented.
Understand what you want to claim, but can't follow. Why do you think so?
If you want to follow the
Spring policy I think you should formulate an alternative proposal which
describes when it is OK to use Java 5 and when it is not.
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.
I simply still can't see how Java 5 will help us significantly.
Regards,
Jörg
[1]
http://springframework.cvs.sourceforge.net/springframework/spring/src/org/springframework/web/context/request/RequestContextListener.java
[2]
http://springframework.cvs.sourceforge.net/springframework/spring/src/org/springframework/web/filter/RequestContextFilter.java
