RE: [Important]: JDK issues
Vadim Gritsenko wrote: PS While we are at this issue... Can you also compile excalibur with InformixDataSource included? This would close http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8875. I really would like to, but unfortunately I don't have the Informix Driver and can't get the download working... Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Important]: JDK issues
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] Vadim Gritsenko wrote: PS While we are at this issue... Can you also compile excalibur with InformixDataSource included? This would close http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8875. I really would like to, but unfortunately I don't have the Informix Driver and can't get the download working... I'm luckier; I've managed to get it. Let me know how I can help you. Vadim Carsten excalibur-datasource-1.0-20020627.jar Description: Binary data - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Important]: JDK issues
Vadim Gritsenko wrote: It's a non-issue comparing to the real issue: 1. Compiling with JDK1.4 against JDK1.4's rt.jar gives incompatible with 1.3 code (IIRC, StringBuffer.append() issue) 2. Compiling with JDK1.4 against JDK1.3's rt.jar gives incompatible with 1.4 code (JDBC 3.0 is not in JDK1.3) Where is the exit from this loop? Will compilation with JDK1.4 against JDK1.3's rt.jar but with JDBC 3.0 in front of it help? Yes, this is much more complicated than it should be. The best solution would be to make only source distributions and skip the binary ones :( Or to make two binary distributions, one for JDK 1.3 and one for JDK 1.4... Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
Vadim Gritsenko wrote: From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] Carsten Ziegeler wrote: Stefano Mazzocchi wrote: Carsten Ziegeler wrote: Christian Haul wrote: there's a -target release switch to javac. Yes, and this is set to 1.2 (I hope) and afaiu it affects only the byte-code but not the libraries/packages used for compilation. In Ant, there is a 'classic' compilation mode. Did you turn that on? Yes, but with the same result. The compiler parameter in Ant choses the compiler, but not the set of runtime classes used to compile sources. For this, we should use the bootclasspath parameter, which allows cross-compilation for a different target JDK (not only classfile format set by target.vm, but also runtime classes). See more info on this at http://java.sun.com/j2se/1.4/docs/tooldocs/windows/javac.html#crosscomp-options Now the problem is how do we handle this in the build as I think we cannot add a JDK 1.2 rt.jar in Cocoon's CVS ? It's a non-issue comparing to the real issue: 1. Compiling with JDK1.4 against JDK1.4's rt.jar gives incompatible with 1.3 code (IIRC, StringBuffer.append() issue) 2. Compiling with JDK1.4 against JDK1.3's rt.jar gives incompatible with 1.4 code (JDBC 3.0 is not in JDK1.3) Where is the exit from this loop? Will compilation with JDK1.4 against JDK1.3's rt.jar but with JDBC 3.0 in front of it help? Damn you're right : I was focused on the StringBuffer.append() problem, and forgot about JDBC. Can't dynamic proxies help for this ? This was proposed in http://marc.theaimsgroup.com/?l=xml-cocoon-devm=101904196229220w=2 but there was no follow up. Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
Carsten Ziegeler wrote: Vadim Gritsenko wrote: It's a non-issue comparing to the real issue: 1. Compiling with JDK1.4 against JDK1.4's rt.jar gives incompatible with 1.3 code (IIRC, StringBuffer.append() issue) 2. Compiling with JDK1.4 against JDK1.3's rt.jar gives incompatible with 1.4 code (JDBC 3.0 is not in JDK1.3) Where is the exit from this loop? Will compilation with JDK1.4 against JDK1.3's rt.jar but with JDBC 3.0 in front of it help? Yes, this is much more complicated than it should be. The best solution would be to make only source distributions and skip the binary ones :( Or to make two binary distributions, one for JDK 1.3 and one for JDK 1.4... I would say, let's make two binary dists and get over with this. It seems that there are many more issues than we are aware of. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
Will compilation with JDK1.4 against JDK1.3's rt.jar but with JDBC 3.0 in front of it help? Yes, this is much more complicated than it should be. The best solution would be to make only source distributions and skip the binary ones :( Or to make two binary distributions, one for JDK 1.3 and one for JDK 1.4... I would say, let's make two binary dists and get over with this. It seems that there are many more issues than we are aware of. +1 - 1.4 is the JDK of pain. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Important]: JDK issues
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Carsten Ziegeler wrote: Vadim Gritsenko wrote: It's a non-issue comparing to the real issue: 1. Compiling with JDK1.4 against JDK1.4's rt.jar gives incompatible with 1.3 code (IIRC, StringBuffer.append() issue) 2. Compiling with JDK1.4 against JDK1.3's rt.jar gives incompatible with 1.4 code (JDBC 3.0 is not in JDK1.3) Where is the exit from this loop? Will compilation with JDK1.4 against JDK1.3's rt.jar but with JDBC 3.0 in front of it help? Yes, this is much more complicated than it should be. The best solution would be to make only source distributions and skip the binary ones :( Or to make two binary distributions, one for JDK 1.3 and one for JDK 1.4... I would say, let's make two binary dists and get over with this. Ditto. Just make sure that Excalibur is built with appropriate version too - it has JDBC code too. Vadim It seems that there are many more issues than we are aware of. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
Andrew C. Oliver wrote: Will compilation with JDK1.4 against JDK1.3's rt.jar but with JDBC 3.0 in front of it help? Yes, this is much more complicated than it should be. The best solution would be to make only source distributions and skip the binary ones :( Or to make two binary distributions, one for JDK 1.3 and one for JDK 1.4... I would say, let's make two binary dists and get over with this. It seems that there are many more issues than we are aware of. +1 - 1.4 is the JDK of pain. 1.4 is not a pain, 1.3 was a pain, at least when you have to handle it for different Linux distributions. v1.3 from sun was not running on SuSE, that one from IBM was not running on RedHat. v1.4 runs on both, thats why I switched to JDK1.4 with cocoon2.0.2 I would vote for supporting JDK1.4 only. Michael - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
Enke, Michael wrote : snip/ 1.4 is not a pain, 1.3 was a pain, at least when you have to handle it for different Linux distributions. v1.3 from sun was not running on SuSE, that one from IBM was not running on RedHat. v1.4 runs on both, thats why I switched to JDK1.4 with cocoon2.0.2 I would vote for supporting JDK1.4 only. Please don't do that : how many of your customers are running their big app servers with 1.4 ? Not that much, if any. Some of our customers even still run JDK 1.2.2. Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
1.4 is not a pain, 1.3 was a pain, at least when you have to handle it for different Linux distributions. v1.3 from sun was not running on SuSE, that one from IBM was not running on RedHat. v1.4 runs on both, thats why I switched to JDK1.4 with cocoon2.0.2 I would vote for supporting JDK1.4 only. As an OS/X user, I would be pretty grumpy if that happened. Of course Apple might upgrade to JDK1.4 in the next OS revision, but I'd really prefer that Cocoon remain compatible until we know for sure. Jason Foster - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
Sylvain Wallez wrote: Enke, Michael wrote : snip/ 1.4 is not a pain, 1.3 was a pain, at least when you have to handle it for different Linux distributions. v1.3 from sun was not running on SuSE, that one from IBM was not running on RedHat. v1.4 runs on both, thats why I switched to JDK1.4 with cocoon2.0.2 I would vote for supporting JDK1.4 only. Please don't do that : how many of your customers are running their big app servers with 1.4 ? Not that much, if any. Some of our customers even still run JDK 1.2.2. We have just removed some 1.3-only code to play nice with 1.2. We'll make two bin versions, as other projects do. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Important]: JDK issues
Vadim Gritsenko wrote: Ditto. Just make sure that Excalibur is built with appropriate version too - it has JDBC code too. That's the problem I hinted at in my first email. Doing it correctly we would have to build two versions of excalibur (1.2 compatible and 1.4 compatible) ourselfs! And this is something I really don't want to do. This would result in a real nightmare and which version do we keep in our CVS/lib directory? Can we assure that Excalibur is the only component we have to take into account? Now, making our lifes easier I'm in favour of building only a 1.2 compatible version (excalibur and all other projects are mostly build with a JDK 1.2 and not JDK 1.4). So we could make a binary distribution for 1.2,1.3 and that would even run with 1.4 except perhaps when it comes to JDBC. So anyone really requiring JDBC 3.0 has to build Excalibur and Cocoon himself. Comments? Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
On Wednesday 26 June 2002 16:22, Morrison, John wrote: Could we keep two versions of avalon-excalibur-20020612.jar... avalon-excalibur-13-20020612.jar and avalon-excalibur-14-20020612.jar and get Ant to use as appropriate? this sounds like a good idea -- Torsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Important]: JDK issues
Nicola Ken Barozzi wrote: Definately against this. Users with 1.4 will not be able to use the binary dist. Bleah :-P Let's do them a favor, you compile it for them and call it dist-14. Why can't they use the binary dist? 1.4 is compatible to 1.2. I have no problems with building a dist-14 which contains a version of the Cocoon sources compiled with JDK 1.4, but I see no real chance in also compiling other projects like Excalibur especially for JDK 1.4 and put them in the dist-14. It's hard enough to make the dist itself and I'm not very eager to make a build of other projects only to make our dist. Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Important]: JDK issues
From: Carsten Ziegeler [mailto:[EMAIL PROTECTED]] Vadim Gritsenko wrote: Ditto. Just make sure that Excalibur is built with appropriate version too - it has JDBC code too. That's the problem I hinted at in my first email. Doing it correctly we would have to build two versions of excalibur (1.2 compatible and 1.4 compatible) ourselfs! And this is something I really don't want to do. Nobody really wants :) This would result in a real nightmare and which version do we keep in our CVS/lib directory? JDK 1.2 compatible. Can we assure that Excalibur is the only component we have to take into account? ATM, and AFAIK, yes. Now, making our lifes easier I'm in favour of building only a 1.2 compatible version (excalibur and all other projects are mostly build with a JDK 1.2 and not JDK 1.4). I would -1 for following reasons: Since release of 1.4, more and more users for one or another reason move to the JDK1.4. It is real PITA to build Excalibur for developer, and it is double to infinite PITA for the (end) users. Since release 2.0.2, JDK1.4 issue is the issue most of the users complain about and solution to it alone (like two distributions) is good enough reason to make 2.0.3, even if no other changes done. So we could make a binary distribution for 1.2,1.3 and that would even run with 1.4 except perhaps when it comes to JDBC. So anyone really requiring JDBC 3.0 has to build Excalibur and Cocoon himself. If you go with this approach, do at least write really clear and working document on how it is possible for the end user to make working (under JDK1.4) version of Cocoon without using CVS. PS While we are at this issue... Can you also compile excalibur with InformixDataSource included? This would close http://nagoya.apache.org/bugzilla/show_bug.cgi?id=8875. Vadim Comments? Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Important]: JDK issues
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Carsten Ziegeler wrote: Vadim Gritsenko wrote: Ditto. Just make sure that Excalibur is built with appropriate version too - it has JDBC code too. That's the problem I hinted at in my first email. Doing it correctly we would have to build two versions of excalibur (1.2 compatible and 1.4 compatible) ourselfs! And this is something I really don't want to do. This would result in a real nightmare and which version do we keep in our CVS/lib directory? Can we assure that Excalibur is the only component we have to take into account? Now, making our lifes easier I'm in favour of building only a 1.2 compatible version (excalibur and all other projects are mostly build with a JDK 1.2 and not JDK 1.4). So we could make a binary distribution for 1.2,1.3 and that would even run with 1.4 except perhaps when it comes to JDBC. So anyone really requiring JDBC 3.0 has to build Excalibur and Cocoon himself. Definately against this. Users with 1.4 will not be able to use the binary dist. And source dist also! Mind wrong excalibur version. Bleah :-P Let's do them a favor, you compile it for them and call it dist-14. cocoon-2.0.3-se14-src cocoon-2.0.3-se14-bin 'se' for 'special edition' :) Vadim -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
That's the problem I hinted at in my first email. Doing it correctly we would have to build two versions of excalibur (1.2 compatible and 1.4 compatible) ourselfs! And this is something I really don't want to do. This would result in a real nightmare and which version do we keep in our CVS/lib directory? Can we assure that Excalibur is the only component we have to take into account? Now, making our lifes easier I'm in favour of building only a 1.2 compatible version (excalibur and all other projects are mostly build with a JDK 1.2 and not JDK 1.4). So we could make a binary distribution for 1.2,1.3 and that would even run with 1.4 except perhaps when it comes to JDBC. So anyone really requiring JDBC 3.0 has to build Excalibur and Cocoon himself. Definately against this. Users with 1.4 will not be able to use the binary dist. Bleah :-P Let's do them a favor, you compile it for them and call it dist-14. Yes...thats yucky. 1 million emails of gee it doesn't work would ensue. Secondly, one must move forward not backward. Perhaps this is an opportunity, and maybe it points out a weakness in Excalibur that should be corrected. (just saying maybe) -Andy - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
On Wednesday, June 26, 2002, at 03:22 pm, Morrison, John wrote: Could we keep two versions of avalon-excalibur-20020612.jar... avalon-excalibur-13-20020612.jar and avalon-excalibur-14-20020612.jar and get Ant to use as appropriate? I think it would be *very* helpful to establish a standard naming convention and use it on the individual jars to avoid any possible confusion, e.g. the above, or: avalon-excalibur-vm13-20020612.jar and avalon-excalibur-vm14-20020612.jar Stuart. Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos) Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF - Stuart Roebuck [EMAIL PROTECTED] Systems Architect Java, XML, MacOS X, XP, etc. ADOLOS http://www.adolos.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
Andrew C. Oliver wrote: ... So we could make a binary distribution for 1.2,1.3 and that would even run with 1.4 except perhaps when it comes to JDBC. So anyone really requiring JDBC 3.0 has to build Excalibur and Cocoon himself. Definately against this. Users with 1.4 will not be able to use the binary dist. Bleah :-P Let's do them a favor, you compile it for them and call it dist-14. Yes...thats yucky. 1 million emails of gee it doesn't work would ensue. This is not a problem. Every Cocoon developer just forwards the mail to Carl, just in case he hasen't read it ;-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
On Wednesday, June 26, 2002, at 03:59 pm, Stuart Roebuck wrote: On Wednesday, June 26, 2002, at 03:22 pm, Morrison, John wrote: Could we keep two versions of avalon-excalibur-20020612.jar... avalon-excalibur-13-20020612.jar and avalon-excalibur-14-20020612.jar and get Ant to use as appropriate? I think it would be *very* helpful to establish a standard naming convention and use it on the individual jars to avoid any possible confusion, e.g. the above, or: avalon-excalibur-vm13-20020612.jar and avalon-excalibur-vm14-20020612.jar Second thoughts, how about: avalon-excalibur-20020612.vm13.jar avalon-excalibur-20020612.vm14.jar cocoon.vm13.jar cocoon.vm14.jar etc. ...which might make it easier to automate the build process. If we added a /lib/core/vm13 and a /lib/core/vm14 directory in the cocoon source tree we could have both binaries in there whilst allowing folk to 'cvs ignore' out the one they don't need and save some bandwidth. Stuart. Public Key - 1024D/88DD65AF 2001-11-23 Stuart Roebuck (Adolos) Key fingerprint = 89D9 E405 F8B1 9B22 0FA2 F2C1 9E57 5AB1 88DD 65AF - Stuart Roebuck [EMAIL PROTECTED] Systems Architect Java, XML, MacOS X, XP, etc. ADOLOS http://www.adolos.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Important]: JDK issues
From: Stuart Roebuck [mailto:[EMAIL PROTECTED]] On Wednesday, June 26, 2002, at 03:59 pm, Stuart Roebuck wrote: On Wednesday, June 26, 2002, at 03:22 pm, Morrison, John wrote: Could we keep two versions of avalon-excalibur-20020612.jar... avalon-excalibur-13-20020612.jar and avalon-excalibur-14-20020612.jar and get Ant to use as appropriate? I think it would be *very* helpful to establish a standard naming convention and use it on the individual jars to avoid any possible confusion, e.g. the above, or: avalon-excalibur-vm13-20020612.jar and avalon-excalibur-vm14-20020612.jar Second thoughts, how about: avalon-excalibur-20020612.vm13.jar avalon-excalibur-20020612.vm14.jar cocoon.vm13.jar cocoon.vm14.jar etc. ...which might make it easier to automate the build process. If we added a /lib/core/vm13 and a /lib/core/vm14 directory in the cocoon source tree we could have both binaries in there whilst allowing folk to 'cvs ignore' out the one they don't need and save some bandwidth. I can't say I'm keen (even though I suggested this approach!) purely from the fact that you'd have two versions to maintain. I do wish JJAR was finished... :( Could part of the build process cvs co excalibur and build it too? :-/ J. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Important]: JDK issues
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Morrison, John wrote: I do wish JJAR was finished... :( Well, it works, Centipede is using it with great satisfaction. In that case - would this be a (possible) solution? J. === Information in this email and any attachments are confidential, and may not be copied or used by anyone other than the addressee, nor disclosed to any third party without our permission. There is no intention to create any legally binding contract or other commitment through the use of this email. Experian Limited (registration number 653331). Registered office: Talbot House, Talbot Street, Nottingham NG1 5HF - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
Morrison, John wrote: From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Morrison, John wrote: I do wish JJAR was finished... :( Well, it works, Centipede is using it with great satisfaction. In that case - would this be a (possible) solution? Hmmm... you mean make checking for JDK part of the build and getting the appropriate version for the build in process? If so yes, it can be done, although a simple ant http get would suffice... hmmm And it doesn't resolve the double binary distribution problem. Do you have a more detailed course of action in mind? -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) - - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
Vadim Gritsenko wrote: From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] Carsten Ziegeler wrote: Stefano Mazzocchi wrote: Carsten Ziegeler wrote: Christian Haul wrote: there's a -target release switch to javac. Yes, and this is set to 1.2 (I hope) and afaiu it affects only the byte-code but not the libraries/packages used for compilation. In Ant, there is a 'classic' compilation mode. Did you turn that on? Yes, but with the same result. The compiler parameter in Ant choses the compiler, but not the set of runtime classes used to compile sources. For this, we should use the bootclasspath parameter, which allows cross-compilation for a different target JDK (not only classfile format set by target.vm, but also runtime classes). See more info on this at http://java.sun.com/j2se/1.4/docs/tooldocs/windows/javac.html#crosscomp- options Now the problem is how do we handle this in the build as I think we cannot add a JDK 1.2 rt.jar in Cocoon's CVS ? It's a non-issue comparing to the real issue: 1. Compiling with JDK1.4 against JDK1.4's rt.jar gives incompatible with 1.3 code (IIRC, StringBuffer.append() issue) 2. Compiling with JDK1.4 against JDK1.3's rt.jar gives incompatible with 1.4 code (JDBC 3.0 is not in JDK1.3) Where is the exit from this loop? Can't we make two different binary releases, one for 1.3 and 1.4 and write a big WARNING note in a very visible place? -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. [EMAIL PROTECTED] Friedrich Nietzsche - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Important]: JDK issues
From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Morrison, John wrote: From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Morrison, John wrote: I do wish JJAR was finished... :( Well, it works, Centipede is using it with great satisfaction. I'll have to take another look. I've not see any work done on it for a while. In that case - would this be a (possible) solution? Hmmm... you mean make checking for JDK part of the build and getting the appropriate version for the build in process? If so yes, it can be done, although a simple ant http get would suffice... hmmm Yes, it probably would for developers, not sure theres an advantage there over sticking it in cvs. And it doesn't resolve the double binary distribution problem. No, it doesn't :( Do you have a more detailed course of action in mind? I didn't but... rather than delivering the war in the binary distribution, would it be an idea to deliver a zip with the 1.4 bit's missing and a script to download/build the war... Huh, maybe on second thoughts this is far too much hassle. Maybe it would be worth it if *all* the jar files came that way but... :( J. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
It seems to me it would be nice if: JDK dependant code seperated from the non-JDK dependant code. The source and binary distributions BOTH included the jdk dependant code precompiled, with an option to recompile it or not provided the correct JDK. At runtime the JDK version were detected and the correct class was loaded dynamically. Of course, I'm a little dull so maybe this is a bad idea and its just not obvious to me as to why. -Andy John Morrison wrote: From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Morrison, John wrote: From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]] Morrison, John wrote: I do wish JJAR was finished... :( Well, it works, Centipede is using it with great satisfaction. I'll have to take another look. I've not see any work done on it for a while. In that case - would this be a (possible) solution? Hmmm... you mean make checking for JDK part of the build and getting the appropriate version for the build in process? If so yes, it can be done, although a simple ant http get would suffice... hmmm Yes, it probably would for developers, not sure theres an advantage there over sticking it in cvs. And it doesn't resolve the double binary distribution problem. No, it doesn't :( Do you have a more detailed course of action in mind? I didn't but... rather than delivering the war in the binary distribution, would it be an idea to deliver a zip with the 1.4 bit's missing and a script to download/build the war... Huh, maybe on second thoughts this is far too much hassle. Maybe it would be worth it if *all* the jar files came that way but... :( J. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Important]: JDK issues
Stefano Mazzocchi wrote: Carsten Ziegeler wrote: Christian Haul wrote: there's a -target release switch to javac. Yes, and this is set to 1.2 (I hope) and afaiu it affects only the byte-code but not the libraries/packages used for compilation. In Ant, there is a 'classic' compilation mode. Did you turn that on? Yes, but with the same result. Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
Carsten Ziegeler wrote: Stefano Mazzocchi wrote: Carsten Ziegeler wrote: Christian Haul wrote: there's a -target release switch to javac. Yes, and this is set to 1.2 (I hope) and afaiu it affects only the byte-code but not the libraries/packages used for compilation. In Ant, there is a 'classic' compilation mode. Did you turn that on? Yes, but with the same result. The compiler parameter in Ant choses the compiler, but not the set of runtime classes used to compile sources. For this, we should use the bootclasspath parameter, which allows cross-compilation for a different target JDK (not only classfile format set by target.vm, but also runtime classes). See more info on this at http://java.sun.com/j2se/1.4/docs/tooldocs/windows/javac.html#crosscomp-options Now the problem is how do we handle this in the build as I think we cannot add a JDK 1.2 rt.jar in Cocoon's CVS ? Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Important]: JDK issues
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]] Carsten Ziegeler wrote: Stefano Mazzocchi wrote: Carsten Ziegeler wrote: Christian Haul wrote: there's a -target release switch to javac. Yes, and this is set to 1.2 (I hope) and afaiu it affects only the byte-code but not the libraries/packages used for compilation. In Ant, there is a 'classic' compilation mode. Did you turn that on? Yes, but with the same result. The compiler parameter in Ant choses the compiler, but not the set of runtime classes used to compile sources. For this, we should use the bootclasspath parameter, which allows cross-compilation for a different target JDK (not only classfile format set by target.vm, but also runtime classes). See more info on this at http://java.sun.com/j2se/1.4/docs/tooldocs/windows/javac.html#crosscomp- options Now the problem is how do we handle this in the build as I think we cannot add a JDK 1.2 rt.jar in Cocoon's CVS ? It's a non-issue comparing to the real issue: 1. Compiling with JDK1.4 against JDK1.4's rt.jar gives incompatible with 1.3 code (IIRC, StringBuffer.append() issue) 2. Compiling with JDK1.4 against JDK1.3's rt.jar gives incompatible with 1.4 code (JDBC 3.0 is not in JDK1.3) Where is the exit from this loop? Will compilation with JDK1.4 against JDK1.3's rt.jar but with JDBC 3.0 in front of it help? Vadim Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
[Important]: JDK issues
Hi, during my testing of the protected sample I found some interesting aspects of choosing the JDK for compiling/running Cocoon that some of you might not know: Question: If Cocoon compiles with JDK 1.3 and JDK 1.4 without any problems, does this mean that a version compiled with JDK 1.4 also runs with JDK 1.3? Answer: No (!) - At first, I was a little bit surprised by this, as Cocoon compiles with both versions, so Cocoon does not use any method of JDK 1.4 which is not in JDK 1.3. So it should be compatible! But exactly the above statement is wrong. Let's have a look at an example: CODE StringBuffer a = new StringBuffer(a); StringBuffer b = new StringBuffer(b); a.append(b); /CODE Now, JDK 1.3 has only a method append( Object ) whereas JDK 1.4 offers a new method append( StringBuffer ). So, if you compile the above with JDK 1.4 a reference to the method append( StringBuffer ) is in the compiled code. And when you run it with JDK 1.3 you get a NoSuchMethodException. But of course, the above compiles with JDK 1.3 as well, as the method append( Object ) is used then. And this works with JDK 1.3 and JDK 1.4 as well. That's nice, isn't it? So, I learn from this that the JDK used for compilation should be the same used for running Cocoon. If you follow this rule, nothing bad could happen... ...but what about all the other projects we use (Avalon, FOP, Batik, Xalan, Xerces - to name only a few)? With which version are they compiled? Do they use code like the one above? I would really like to know if Sun has an answer on this one! Or did I miss something? Carsten Carsten Ziegeler Chief Architect Open Source Group, SN AG -- Cocoon Consulting, Training and Projects -- mailto:[EMAIL PROTECTED] http://www.s-und-n.de http://ziegeler.bei.t-online.de - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
On 24.Jun.2002 -- 01:10 PM, Carsten Ziegeler wrote: Or did I miss something? there's a -target release switch to javac. Chris. -- C h r i s t i a n H a u l [EMAIL PROTECTED] fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
RE: [Important]: JDK issues
Christian Haul wrote: there's a -target release switch to javac. Yes, and this is set to 1.2 (I hope) and afaiu it affects only the byte-code but not the libraries/packages used for compilation. Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
On Monday 24 June 2002 13:10, Carsten Ziegeler wrote: . . . So, I learn from this that the JDK used for compilation should be the same used for running Cocoon. If you follow this rule, nothing bad could happen... . . . But if you compile with JDK 1.3, aren't you safe that it will run fine on 1.4? I don't know if a reference JDK version is defined for final compiling and testing among committers, but it might be a good idea to select one. -Bertrand - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
On Mon, Jun 24, 2002 at 01:22:33PM +0200, Carsten Ziegeler wrote: Christian Haul wrote: there's a -target release switch to javac. Yes, and this is set to 1.2 (I hope) and afaiu it affects only the byte-code but not the libraries/packages used for compilation. Nice work Carsten :) I guess Excalibur wasn't compiled with -target 1.2.. I just rolled back Excalibur and Avalon to -D 6/12/02 and -D 3/14/02 respectively, fixed a minor compilation error, and with those jars everything works (barring natural cocoon brokenness :-)). The jars are at http://www.opensource.socialchange.net.au/tmp/cocoon/ if anyone wants to play. --Jeff Carsten - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
Re: [Important]: JDK issues
Carsten Ziegeler wrote: Christian Haul wrote: there's a -target release switch to javac. Yes, and this is set to 1.2 (I hope) and afaiu it affects only the byte-code but not the libraries/packages used for compilation. In Ant, there is a 'classic' compilation mode. Did you turn that on? -- Stefano Mazzocchi One must still have chaos in oneself to be able to give birth to a dancing star. [EMAIL PROTECTED] Friedrich Nietzsche - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
