Bertrand Delacretaz escribió:
On 10/9/06, Antonio Gallardo <[EMAIL PROTECTED]> wrote:
...Just some question: it is the same for 2.1, right? What is 2
different
blocks with different jvm requirement needs the same jar?...
I was mainly thinking about 2.2, but in your case, if a jar is
compiled for 1.4 it will work with 1.5, right?
I am thinking in 2.2 too. The above reference to 2.1 is just a sample of
what we are repeating for 2.2. Because we claim 2.1 is java 1.3 when it
fact few of us care about this compatibility and some blocks does not
compile at all. This somehow makes us look like a buggy project. As a
sample try to download the 2.1 and try to compile it as is shipped in
java 1.3 it simply does not compiled.
Now answering your above comment: "Yes, but not the opposite".
The opposite case is what made me think about the problem we are
overlooking. Please note, cocoon 2.2 will be around at least 2 years
from now, in about 1 year java 1.4 will be in the same category as we
look at java 1.3.1 now. I will try to describe the situation: "Nobody
cares about it." Many (I would said: "most") of the cocoon developers
does not have a java 1.3.1 version installed in his machines to
compatibility test the code they are writing for cocoon this days, and
this is not new, proof of that are the many times I needed fix some java
1.3 incompatibilities for perhaps nobody, because seems like nobody uses
java 1.3 with cocoon this days. But since I am a committer and I have a
"contract" with our user community, hence I care about it. But this
effort is worthless since also looks our user base also does not use
this days java 1.3 at all."
Now, please add 1 year in the time and change jvm 1.3 with jvm 1.4 and
read it again we will be in the same place wasting committers resources
keeping a worthless compatibility. I can tell you how many times I
needed to recompiled the sources, because the jar proect does not ship
anymore a java 1.3 compatible jar. And this is why I am trying to call
again to rethink this issue just before the official of 2.2, because if
not I foresee a second round of the above described problems in a cocoon
2.2 edition.
In some cases switching to a newer jar only means to copy a new jar into
the right directory, in other cases it means rewriting some parts of our
current components to make them run with the updated version, in this
second case is where I see the problem. The proof of that is new qdox
which API changed hence as a user it does not easy to switch unless he
maintains his own components. Another perhaps more used component (I
would said a critical one) is ehcache, each new version often introduce
new API.
Best Regards,
Antonio Gallardo.
