You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Antonio Gallardo <ag...@agssa.net> on 2006/10/09 06:01:48 UTC
[HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
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/
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Ralph Goers <Ra...@dslextreme.com>.
Antonio Gallardo wrote:
> 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:
Yes, Maven does not care about Java versions, but it does care about the
artifact versions. With the fix for MNG-1577 users can specify whatever
version they want at runtime. The block needs to be compiled with a 1.4
version of the component.
Ralph
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Antonio Gallardo <ag...@agssa.net>.
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/
>>
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Ralph Goers <Ra...@dslextreme.com>.
1. I don't see the point. There was a -1 that is unlikely to be changed.
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.
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/
>
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Joerg Heinicke <jo...@gmx.de>.
On 09.10.2006 06:01, Antonio Gallardo wrote:
> Should we call for a new votation about the
> minimal java version for cocoon 2.2?
No, please don't.
Jörg
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Joerg Heinicke <jo...@gmx.de>.
On 09.10.2006 23:03, Antonio Gallardo wrote:
> 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.
It should. Everything else is a bug. The JCR block, known to be not 1.3
compatible is switched off. IIRC this is due to the API only available
as 1.4 jar, isn't it?
> "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
That might be true. But as soon as we get aware of such a problem it
gets fixed.
> But this effort is worthless since also looks our user base also does
> not use this days java 1.3 at all."
If this would be true we would not get informed about such errors. If
this would be true Cocoon could not be seen as a buggy project as nobody
would notice the problems. Sorry, but you contradict yourself.
> 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.
Where is the problem? As soon as we have released 2.2 and the blocks
they can start independent release cycles.
> Another perhaps more used component (I would said a critical one) is
> ehcache, each new version often introduce new API.
Though you take it just as an example I can say that ehcache won't get a
problem that fast. They also care for their users, which is besides
Cocoon for example Spring. Spring even claim 1.3 compatibility with
their latest 2.0 release. So ehcache will provide 1.4 compatibility
probably for a long time.
Sorry, but you have no new points.
Jörg
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Jorg Heymans <jh...@apache.org>.
Reinhard Poetz wrote:
>> For 2.2, it would be cool to have this info in the blocks themselves -
>> do the Maven POMs allow for some "JDK requirements" metadata?
not that i know of. There is the <prerequisites> element but that's only
used for the maven version. Nothing prevents us though from just setting
a plain property in the pom as an indication of the jdk version. I don't
see a way of enforcing it ATM.
> You can configure the compiler plugin by setting the source and target
> version of your code. Usually they are set in the root pom but for
> Cocoon it has been commented out for some reasons (Jorg?)
I remember commenting it out a long time ago, probably because at the
time it wasn't decided yet on what JDK 2.2 should be able run. Feel free
to enable it again.
HTH
Jorg
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Reinhard Poetz <re...@apache.org>.
Bertrand Delacretaz wrote:
> On 10/9/06, Antonio Gallardo <ag...@agssa.net> wrote:
>
>> ...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....
>
> I think we voted on this a while ago: the 2.1 core and most blocks
> must work with 1.3, but some blocks might not. So it's not a surprise.
>
> If we want to make sure 2.1 compiles with JDK 1.3 as shipped, we could
> add a notice to the release instructions, that this must be tested
> before releasing - it's only a matter of disabling blocks which do not
> compile with 1.3.
>
> For 2.2, it would be cool to have this info in the blocks themselves -
> do the Maven POMs allow for some "JDK requirements" metadata?
You can configure the compiler plugin by setting the source and target version
of your code. Usually they are set in the root pom but for Cocoon it has been
commented out for some reasons (Jorg?).
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
___________________________________________________________
Der fr�he Vogel f�ngt den Wurm. Hier gelangen Sie zum neuen Yahoo! Mail: http://mail.yahoo.de
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/9/06, Antonio Gallardo <ag...@agssa.net> wrote:
> ...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....
I think we voted on this a while ago: the 2.1 core and most blocks
must work with 1.3, but some blocks might not. So it's not a surprise.
If we want to make sure 2.1 compiles with JDK 1.3 as shipped, we could
add a notice to the release instructions, that this must be tested
before releasing - it's only a matter of disabling blocks which do not
compile with 1.3.
For 2.2, it would be cool to have this info in the blocks themselves -
do the Maven POMs allow for some "JDK requirements" metadata?
-Bertrand
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Antonio Gallardo <ag...@agssa.net>.
Bertrand Delacretaz escribió:
> On 10/9/06, Antonio Gallardo <ag...@agssa.net> 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.
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/9/06, Antonio Gallardo <ag...@agssa.net> 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?
-Bertrand
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Antonio Gallardo <ag...@agssa.net>.
Bertrand Delacretaz escribió:
> I think the only way to handle this is to decide on a JVM version for
> the core, and accept that some "non-core" blocks might have different
> requirements.
+1.
Just some question: it is the same for 2.1, right? What is 2 different
blocks with different jvm requirement needs the same jar?
Best Regards,
Antonio Gallardo.
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Vadim Gritsenko <va...@reverycodes.com>.
Bertrand Delacretaz wrote:
> I think the only way to handle this is to decide on a JVM version for
> the core, and accept that some "non-core" blocks might have different
> requirements.
+1
Vadim
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Antonio Gallardo <ag...@agssa.net>.
Hi Simone,
I agree with you, basically, it is a chicken egg problem, if we don't
set java 1.5 as the minimal jvm, we will never start using typed
collections, for-each etc. The fact is that most of us is using this new
cool features and will be fine to use them in our cocoon code too.
Best Regards,
Antonio Gallardo.
Simone Gianni escribió:
> Bertrand Delacretaz wrote:
>> Does anything prevent us from having some blocks that require 1.5,
>> while the core and "core blocks" (we might need to define which ones
>> these are, but most of them are evident I thin) require 1.4?
> Nope, except that it could be a pain for users, but after all it would
> go this way in any case, I don't think anyone is planing to rewrite
> all blocks to use typed collections, for-each etc.. before the 2.2
> release.
>
> Anyway I'm currently running a couple of 1.5 applications successfully
> on 1.4 using Retrotranslater. Don't know if it works with cocoon : it
> is not java 1.5, so it obviously works :)
>
> Considering that it would take years before moving the current code
> base to 1.5, and we could defer moving core as the last part,
> Retrotranslator could fill the hole while our most conservative users
> consider the move to 1.5.
>
> We could experiment on a simple block to see if Retrotranslator works
> correctly, and if it works agree on a plan on moving blocks to 1.5
> progressively, moving core as the last part, taking enough time to be
> realistic on our efforts and grant a smooth change.
>
> Maybe this could be a way to gain consensus?
>
> Simone
>
> P.S. Java 1.5 also brings another advantage : the xml-apis contained
> in 1.5 is more or less the same we ship with cocoon (and since 1.6 is
> so near, it will not change soon), and Xalan and Xerces have been
> repackaged, that means that all the Shielding system is by far less
> critical on 1.5. It's actually a big problem to have xml-apis in the
> war, ever tried to use any JRE class writing or reading XML from
> inside a flow or a cocoon component, like Properties.toXml?
> ClassCastException. Just remove the xml-apis and xmlParsers-api jars,
> they are already in 1.5 in very similar versions, and everything seems
> to work correctly.
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Simone Gianni <s....@thebug.it>.
Bertrand Delacretaz wrote:
> Does anything prevent us from having some blocks that require 1.5,
> while the core and "core blocks" (we might need to define which ones
> these are, but most of them are evident I thin) require 1.4?
Nope, except that it could be a pain for users, but after all it would
go this way in any case, I don't think anyone is planing to rewrite all
blocks to use typed collections, for-each etc.. before the 2.2 release.
Anyway I'm currently running a couple of 1.5 applications successfully
on 1.4 using Retrotranslater. Don't know if it works with cocoon : it is
not java 1.5, so it obviously works :)
Considering that it would take years before moving the current code base
to 1.5, and we could defer moving core as the last part, Retrotranslator
could fill the hole while our most conservative users consider the move
to 1.5.
We could experiment on a simple block to see if Retrotranslator works
correctly, and if it works agree on a plan on moving blocks to 1.5
progressively, moving core as the last part, taking enough time to be
realistic on our efforts and grant a smooth change.
Maybe this could be a way to gain consensus?
Simone
P.S. Java 1.5 also brings another advantage : the xml-apis contained in
1.5 is more or less the same we ship with cocoon (and since 1.6 is so
near, it will not change soon), and Xalan and Xerces have been
repackaged, that means that all the Shielding system is by far less
critical on 1.5. It's actually a big problem to have xml-apis in the
war, ever tried to use any JRE class writing or reading XML from inside
a flow or a cocoon component, like Properties.toXml? ClassCastException.
Just remove the xml-apis and xmlParsers-api jars, they are already in
1.5 in very similar versions, and everything seems to work correctly.
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
Posted by Bertrand Delacretaz <bd...@apache.org>.
On 10/9/06, Antonio Gallardo <ag...@agssa.net> wrote:
> ...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!...
Does anything prevent us from having some blocks that require 1.5,
while the core and "core blocks" (we might need to define which ones
these are, but most of them are evident I thin) require 1.4?
The situation that you describe will certainly happen for other
blocks, and at the same time we might have some blocks that do not
compile with 1.5.
I think the only way to handle this is to decide on a JVM version for
the core, and accept that some "non-core" blocks might have different
requirements.
-Bertrand