Ralph Goers escribió:
1. I don't see the point. There was a -1 that is unlikely to be changed.
I am providing more reasons as brain food. I think people can change his
mind over the time when more facts arises.
2. Since we will be distributing binaries with Maven - I would think
that as long as all the Cocoon components are compiled with JDK 1.4
and none of the core dependencies require more than that that things
should be OK. A Cocoon user who is OK with Java 5 is certainly free
to use Qdox 1.6 (or whatever) in their build and at runtime -
assuming, of course, that the component in question has maintained
binary compatibility.
It is not going to work. AFAIK, maven does not care about java versions.
Hence, if the jar in the maven repo is being compiled for 1.5 we may
receive the tipical compilation errors for cocoon beking compiled in
java 1.4:
"class file has wrong version 49.0, should be 48.0"
Hence, because the cocoon 2.2 is tied with 1.4.2, nobody can move to 1.5 unless
he maintains his own cocoon or forks it.
I have been maintaining the libraries for long time and can tell that it
is not so easy as you are pointing out. Take as a sample the same qdox
lib, there are incompatibilities between releases. I am talking about
API changes or so. We should take into account that not each lib is as
perfect as spring or commons-lang.
Best Regards,
Antonio Gallardo.
Ralph
Antonio Gallardo wrote:
Hi:
I was updating some jars for cocoon 2.1.0. Qdox[1] version 1.6 was
released in August 2006 (we are using now qdox 1.5) and it is
distributed only for java 1.5! I know qdox is not the most used
block, but it rings a bell!
Cocoon 2.2 is not released and we will start to find such cases more
often than what we would like to believe. I mean we will have more
compatibility problems with other libraries that will being released
for java 1.5. It means we will have serious problems updating, it
will be a serious pain updating them. Also, we should take into
account that java 1.6 is just around the corner. So I will be glad if
given this fact, we should reconsider to set 1.5 as the minimal
version for cocoon 2.2.
Another fact: we claim cocoon 2.1 is java 1.3 compatible, but in
practice, we have some blocks that don't work with java 1.3. Some of
them even break the compilation and the user needs to start excluding
this blocks. This is our current situation. Have we plans to repeat
this for cocoon 2.2 for 1.4 vs. 1.5 o 1.6?
Given this facts, I ask you: Should we call for a new votation about
the minimal java version for cocoon 2.2?
WDYT?
Best Regards,
Antonio Gallardo.
[1] http://qdox.codehaus.org/
