Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
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 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.
Bertrand Delacretaz wrote:
On 10/9/06, Antonio Gallardo <[EMAIL PROTECTED]> 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.
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.
On 10/9/06, Antonio Gallardo <[EMAIL PROTECTED]> 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.
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.
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.
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
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.
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? -Bertrand
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
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.
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.
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.
On 10/9/06, Antonio Gallardo <[EMAIL PROTECTED]> 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
Re: [HEADS-UP] Cocoon 2.2 and java 1.5 revisited.
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.
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.
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
[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/
