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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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,
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
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 :)
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
35 matches
Mail list logo
