You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2002/06/24 13:10:32 UTC
[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, S&N AG
------------------------------------------------------------------
Cocoon Consulting, Training and Projects
------------------------------------------------------------------
mailto:cziegeler@s-und-n.de http://www.s-und-n.de
http://ziegeler.bei.t-online.de
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by Bertrand Delacretaz <bd...@codeconsult.ch>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by Jeff Turner <je...@socialchange.net.au>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by Stefano Mazzocchi <st...@apache.org>.
Vadim Gritsenko wrote:
>
> > From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
> >
> > 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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
>>From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>>
>>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-dev&m=101904196229220&w=2 but
there was no follow up.
Sylvain
--
Sylvain Wallez
Anyware Technologies Apache Cocoon
http://www.anyware-tech.com mailto:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by Jason Foster <ja...@uwaterloo.ca>.
> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by "Enke, Michael" <mi...@wincor-nixdorf.com>.
"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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>>>
>>> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by "Andrew C. Oliver" <ac...@apache.org>.
>
>
>>
>> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Important]: JDK issues
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Important]: JDK issues
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> 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 nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Soap/XSP problems
Posted by deepak venugopal <de...@yahoo.com>.
Hello friends,
> > > My company has started developing soap clients
> > based
> > > on XSP and submitting the request to Apache Soap
> > > Server which has services running in pure Java.
> > > For my Java Soap Clients, the soap service used
to
> > > return a Node Element ( XML Document). The Java
> > Client
> > > worked perfectly using the usual following code:
> > >
> > > if( !resp.generatedFault() )
> > > {
> > > Parameter ret = resp.getReturnValue();
> > > bookEl = (Element)ret.getValue();
> > >
> > >
> >
System.out.println(DOM2Writer.nodeToString(bookEl));
> > >
> > > }
> > >
> > > But now since i have started using XSP where the
> > > client looks like :
> > > <soap:call url="http://soap server .....">
> > > <ns1:*method name *
> > > xmlns:ns1="urn:*service name *">
> > > <soap:enc/>
> > > <symbol xsi:type="xsd:string"
> > >
> >
>
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
> > >
> >
>
xmlns:xsd="http://www.w3.org/1999/XMLSchema"><xsp-request:get-parameter
> > > name="symbol"/></symbol>
> > > </ns1:*method name*>
> > > </soap:call>
> > >
> > > ,while working with string return values, the
> > existing
> > > sample code works perfectly, but when xml
objects
> > r
> > > being rcvd i get the error no serializer found
for
> > > org.w3c.node***.
> > > (-- i can solve this error for Java Clients--)
> > >
i understand that encoding style has to b put, but
when in the concerned logic sheet i put for <soap:enc
> as "...XML_LITERAL,,...." it still takes the ENC
type encoding
> > >
> > > Since there are no existing cases in the mail
> > archives
> > > for writing the XSP equivalent of exisiting Java
> > > Clients or any literature on the Net, we are
> > facing
> > > great problems.
> > > If any of you guys have sorted out these kinda
XSP
> > > cases, pls do reply as it wld b of gr8 help.
> > > rgds
> > > DEEPAK.
> > >
> > >
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faq/index.html>
To unsubscribe, e-mail: <co...@xml.apache.org>
For additional commands, e-mail: <co...@xml.apache.org>
Soap/XSP problems
Posted by deepak venugopal <de...@yahoo.com>.
Hello friends,
> > > My company has started developing soap clients
> > based
> > > on XSP and submitting the request to Apache Soap
> > > Server which has services running in pure Java.
> > > For my Java Soap Clients, the soap service used
to
> > > return a Node Element ( XML Document). The Java
> > Client
> > > worked perfectly using the usual following code:
> > >
> > > if( !resp.generatedFault() )
> > > {
> > > Parameter ret = resp.getReturnValue();
> > > bookEl = (Element)ret.getValue();
> > >
> > >
> >
System.out.println(DOM2Writer.nodeToString(bookEl));
> > >
> > > }
> > >
> > > But now since i have started using XSP where the
> > > client looks like :
> > > <soap:call url="http://soap server .....">
> > > <ns1:*method name *
> > > xmlns:ns1="urn:*service name *">
> > > <soap:enc/>
> > > <symbol xsi:type="xsd:string"
> > >
> >
>
xmlns:xsi="http://www.w3.org/1999/XMLSchema-instance"
> > >
> >
>
xmlns:xsd="http://www.w3.org/1999/XMLSchema"><xsp-request:get-parameter
> > > name="symbol"/></symbol>
> > > </ns1:*method name*>
> > > </soap:call>
> > >
> > > ,while working with string return values, the
> > existing
> > > sample code works perfectly, but when xml
objects
> > r
> > > being rcvd i get the error no serializer found
for
> > > org.w3c.node***.
> > > (-- i can solve this error for Java Clients--)
> > >
i understand that encoding style has to b put, but
when in the concerned logic sheet i put for <soap:enc
> as "...XML_LITERAL,,...." it still takes the ENC
type encoding
> > >
> > > Since there are no existing cases in the mail
> > archives
> > > for writing the XSP equivalent of exisiting Java
> > > Clients or any literature on the Net, we are
> > facing
> > > great problems.
> > > If any of you guys have sorted out these kinda
XSP
> > > cases, pls do reply as it wld b of gr8 help.
> > > rgds
> > > DEEPAK.
> > >
> > >
__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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. Bleah :-P
Let's do them a favor, you compile it for them and call it dist-14.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Important]: JDK issues
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
>
> 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
RE: [Important]: JDK issues
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Important]: JDK issues
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Carsten Ziegeler [mailto:cziegeler@s-und-n.de]
>
> 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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Important]: JDK issues
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Important]: JDK issues
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
>
> 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 nicolaken@apache.org
> - verba volant, scripta manent -
> (discussions get forgotten, just code remains)
> ---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by Nicola Ken Barozzi <ni...@apache.org>.
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 nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Important]: JDK issues
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Important]: JDK issues
Posted by Vadim Gritsenko <va...@verizon.net>.
> From: Sylvain Wallez [mailto:sylvain.wallez@anyware-tech.com]
>
> 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:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
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:sylvain@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Important]: JDK issues
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by Stefano Mazzocchi <st...@apache.org>.
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.
<st...@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [Important]: JDK issues
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
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: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [Important]: JDK issues
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
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
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org