You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Stefan Bodewig <bo...@apache.org> on 2005/01/24 09:49:23 UTC
Re: derby build
On Sun, 23 Jan 2005, Andrew McIntyre <fu...@sbcglobal.net> wrote:
> First, many thanks Stephan for cleaning up my attempt at a project
> file for derby!
You're welcome.
> I'll be glad to help get the Derby build going,
Yes, that I'd very much appreciate that.
> It's taken me a while to get subscribed to general@gump due to mail
> client problems on my end.
and still I had to moderate in this mail. Seems you are using a
different address for sending than you've subscribed with.
> Derby has classes which implement interfaces which changed between
> JDK 1.3 and JDK 1.4, such as PreparedStatement, so both versions are
> needed at different times in the build. In Derby's buildfiles, the
> properties j13lib and j14lib are used to reference the different
> versions of the runtime classes to compile against.
By now you can rely on Gump running on JDK 1.4+. I'm not sure which
version of JDBC Kaffe ships with, though.
Does the build process always build against the different runtime,
even if they are not present at all? How? Do you ship with JDBC
interface classes for them?
If so, the solution is to add two new projects to your derby
descriptor with only <jar> elements pointing to those interfaces and
have derby depend on them.
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 26 Jan 2005, Samuel Andrew McIntyre
<fu...@nonintuitive.com> wrote:
> resending with the current account. *sigh*
I've just "allowed" your other address to post as well.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Samuel Andrew McIntyre <fu...@nonintuitive.com>.
resending with the current account. *sigh*
On Jan 25, 2005, at 2:04 AM, Stefan Bodewig wrote:
> Ideally we'd build everything except the JDBC 2.0 stuff using Gump's
> default. And build the JDBC 2.0 stuff with JDK 1.3's rt.jar on the
> bootclasspath.
The easiest way to achieve this would be to set the property j13lib to
the location of the JDK 1.3 jar, and build with
build.sysclasspath=last. I don't know if this is currently possible,
but I'm guessing no.
> Is there any sensible split of targets in the build file in order to
> achieve that?
So, I made a first pass at this and it come out to seven splits. In the
main derby build.xml there are now 7 new targets:
gump_split_1: builds everything up to internal api JDBC 2.0 interfaces
gump_split_2: builds internal api JDBC 2.0 interfaces
gump_split_3: builds up to implementations of JDBC 2.0 interfaces
gump_split_4: builds implementations of JDBC 2.0 interfaces
gump_split_5: builds external api up to JDBC 2.0 interfaces
gump_split_6: builds external api classes for JDBC 2.0
gump_split_7: builds everything else.
So, gump_split_2, 4, and 6 should be built with JDK 1.3's rt.jar, the
rest can be built with JDK 1.4's rt.jar. They should be built in order.
Also, I just realized that all of these need to be built with the
property sane=false, which creates a build with all optimizations
turned on.
I will try in the future to condense these to a smaller number of
targets, but I don't currently know if this is possible. With these
targets, though, i think it might be possible to build derby with gump.
Please let me know if there is more I can do.
Thanks,
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Andrew McIntyre <fu...@sbcglobal.net>.
On Feb 2, 2005, at 2:43 AM, Stefan Bodewig wrote:
> On Tue, 1 Feb 2005, Andrew McIntyre <fu...@sbcglobal.net> wrote:
>
> I still get the same error for gump_split_1, is your target separation
> correct?
It looks like a line in java/engine/org/apache/derby/impl/build.xml was
out of place. I have fixed this. Hopefully tonight there will be a good
build!
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 10 Feb 2005, Andrew McIntyre <fu...@sbcglobal.net> wrote:
> And it did! The latest derby build succeeded! Woohoo!!
Great.
So you can now turn to making it compile under JDK 1.5 as well ;-)
<http://brutus.apache.org/gump/jdk15/db-derby/derby-split-1/gump_work/build_db-derby_derby-split-1.html>
This is the benefit of type erasure, you now need to cast bigDecimal
to BigDecimal.
Cheers
Stefan
--
http://stefanbodewig.blogger.de/
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Andrew McIntyre <fu...@sbcglobal.net>.
On Feb 10, 2005, at 12:50 AM, Stefan Bodewig wrote:
> Should work with the next test build or the public build starting at
> 18:00 PST.
>
> Stefan
And it did! The latest derby build succeeded! Woohoo!!
http://brutus.apache.org/gump/public/db-derby/derby/index.html
Thanks for all your help, Stefan!
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 9 Feb 2005, Samuel Andrew McIntyre
<fu...@nonintuitive.com> wrote:
> Not sure why this is happening, as the classpath that the
> verifysplit target checks for org.apache.derbyBuild.splitmessages
> should be ${basedir}/classes,
which is (err, was ;-) not in your CLASSPATH.
Should work with the next test build or the public build starting at
18:00 PST.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Samuel Andrew McIntyre <fu...@nonintuitive.com>.
On Feb 9, 2005, at 10:20 AM, Andrew McIntyre wrote:
> So close! One last problem:
Ha! I spoke too soon. Now we're at the last split, but there's yet
another problem. From build_db-derby_derby:
verifysplit:
noSplit:
[echo] ***** SplitMessages not available *****
[echo] ***** Run "all" target first *****
Not sure why this is happening, as the classpath that the verifysplit
target checks for org.apache.derbyBuild.splitmessages should be
${basedir}/classes, which is where the classes are being built, and the
target where the splitmessages class is built succeeded without error.
Any ideas?
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Andrew McIntyre <fu...@nonintuitive.com>.
On Feb 9, 2005, at 2:22 AM, Stefan Bodewig wrote:
> Woohoo!
>
> <http://brutus.apache.org/gump/public/db-derby/derby-split-2/
> gump_work/build_db-derby_derby-split-2.html>
So close! One last problem:
[javac] Found 1 semantic error compiling "Driver20.java":
[javac] 56. public class Driver20 extends InternalDriver
implements Driver {
[javac] . . .
[javac] 275. }
[javac] >
[javac] *** Semantic Error: A class file was not generated for the
type "org.apache.derby.jdbc.Driver20" because a library method that it
depends on was not found. See system messages for more information.
[javac] Found 1 system error:
[javac] *** Semantic Error: A non-standard version of the type
"java.lang.Throwable" was found. Class files that depend on this type
may not have been generated.
This also appears to be an issue with newer versions of Jikes when
compiling with the JDK1.3 runtime libraries. As far as I can tell, the
fix is to add the -source 1.3 option to this particular <javac> task. I
have done that in a way that it will not interfere with the use of
javac or previous versions of Jikes that do not support the -source
option.
andrew
Re: derby build
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 8 Feb 2005, Samuel Andrew McIntyre
<fu...@nonintuitive.com> wrote:
> I will turn off the deprecation flag for now in the splits that use
> Jikes.
Woohoo!
<http://brutus.apache.org/gump/public/db-derby/derby-split-2/gump_work/build_db-derby_derby-split-2.html>
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 8 Feb 2005, Samuel Andrew McIntyre
<fu...@nonintuitive.com> wrote:
> This appears to be a Jikes issue:
We hit the same issue with the Kaffe builds IIRC. I think Dims
installed/compiled a newer jikes version so it should be on brutus
somewhere ...
I'll try to dig out some time to search for it, but don't hold your
breath.
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Samuel Andrew McIntyre <fu...@nonintuitive.com>.
On Feb 7, 2005, at 11:06 PM, Samuel Andrew McIntyre wrote:
> The empty property is only used to set the bootclasspath to the
> location of the empty jar file. So, I have set the empty property for
> splits 2, 4, and 6 to the java-runtime-1.3 jarpath.
Getting closer. Current error is:
[javac] Found 1 semantic error compiling
"BrokeredPreparedStatement.java":
[javac] 307. public final void setUnicodeStream(int
parameterIndex, InputStream x, int length) throws SQLException
[javac]
^-------------------------------------------------------------^
[javac] *** Semantic Error: The overridden method "void
setUnicodeStream(int parameterIndex, java.io.InputStream x, int length)
throws java.sql.SQLException;" is deprecated in type
"java.sql.PreparedStatement".
This appears to be a Jikes issue:
http://oss.software.ibm.com/developerworks/bugs/?
func=detailbug&bug_id=4058&group_id=10
I will turn off the deprecation flag for now in the splits that use
Jikes.
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Samuel Andrew McIntyre <fu...@nonintuitive.com>.
On Feb 7, 2005, at 12:14 PM, Stefan Bodewig wrote:
> I see. Setting includeruntime to false should help, doesn't it?
If you mean the includeJavaRuntime and includeAntRuntime properties,
then no. If I remember correctly, if bootclasspath is empty or null
then the Jikes CompilerAdapter will add the Java runtime classes to the
classpath even if those properties are set to false.
> That should be enough. I wasn't sure whether you actually used the
> empty property in other places as well, so I suggested yet another
> property.
The empty property is only used to set the bootclasspath to the
location of the empty jar file. So, I have set the empty property for
splits 2, 4, and 6 to the java-runtime-1.3 jarpath.
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Stefan Bodewig <bo...@apache.org>.
On Fri, 4 Feb 2005, Samuel Andrew McIntyre
<fu...@nonintuitive.com> wrote:
> Actually, in order to prevent Ant from putting the runtime libraries
> on jikes' classpath, we currently set the bootclasspath attribute on
> all <javac> tasks to ${empty}, which is the location of an empty jar
> file.
I see. Setting includeruntime to false should help, doesn't it?
> So, do we need to define empty=java-runtime-1.3's jarpath for the
> splits that need them (2, 4, and 6)? Or is there more to do than
> that?
That should be enough. I wasn't sure whether you actually used the
empty property in other places as well, so I suggested yet another
property.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Samuel Andrew McIntyre <fu...@nonintuitive.com>.
On Feb 4, 2005, at 7:53 AM, Stefan Bodewig wrote:
> The only solution I see is that we define a property in Gump pointing
> to JDK 1.3's rt.jar and you add this to the appropriate bootclasspath
> attributes.
>
> If you make this new property default to ${empty}, there shouldn't be
> any changes to your normal build. And with build.sysclasspath being
> set to last, it will be seen by jikes before JDK 1.4's rt.jar in Gump.
Actually, in order to prevent Ant from putting the runtime libraries on
jikes' classpath, we currently set the bootclasspath attribute on all
<javac> tasks to ${empty}, which is the location of an empty jar file.
Is this what you mean? e.g.:
<javac
bootclasspath="${empty}"
...
</javac>
empty is defined as pointing to tools/java/empty.jar, the empty jar
file. So, do we need to define empty=java-runtime-1.3's jarpath for the
splits that need them (2, 4, and 6)? Or is there more to do than that?
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Stefan Bodewig <bo...@apache.org>.
On Thu, 3 Feb 2005, Samuel Andrew McIntyre
<fu...@nonintuitive.com> wrote:
> The derby build gets past the first split now. The errors in
> derby_split_2, like this one: look like the build is still picking
> up the JDK 1.4 interfaces from somewhere. Any ideas?
Yes.
I modified Ant in December so that build.sysclasspath now also
modifies the bootclasspath. We need this with JDK 1.5 and Kaffe
builds so that we get Xerces into the forked VMs or Jikes.
In the derby builds it is slashing back at us. Jikes gets JDK 1.4's
rt.jar as -bootclasspath and thus it comes in front of JDK 1.3's.
The only solution I see is that we define a property in Gump pointing
to JDK 1.3's rt.jar and you add this to the appropriate bootclasspath
attributes.
If you make this new property default to ${empty}, there shouldn't be
any changes to your normal build. And with build.sysclasspath being
set to last, it will be seen by jikes before JDK 1.4's rt.jar in Gump.
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Samuel Andrew McIntyre <fu...@nonintuitive.com>.
On Feb 2, 2005, at 2:43 AM, Stefan Bodewig wrote:
> Anyway, the derby build has been split into seven pieces, three of
> which should be using JDK 1.3's rt.jar now.
The derby build gets past the first split now. The errors in
derby_split_2, like this one:
[javac] 40. public class BrokeredConnection implements
Connection
[javac] ^----------------^
[javac] *** Semantic Error: The abstract method "void
rollback(java.sql.Savepoint $1) throws java.sql.SQLException;",
inherited from type "java.sql.Connection", is not implemented in the
non-abstract class "org.apache.derby.iapi.jdbc.BrokeredConnection".
look like the build is still picking up the JDK 1.4 interfaces from
somewhere. Any ideas?
Thanks,
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 1 Feb 2005, Andrew McIntyre <fu...@sbcglobal.net> wrote:
> Well, it didn't work. The current error is:
I still get the same error for gump_split_1, is your target separation
correct?
Anyway, the derby build has been split into seven pieces, three of
which should be using JDK 1.3's rt.jar now.
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Stefan Bodewig <bo...@apache.org>.
On Tue, 1 Feb 2005, Andrew McIntyre <fu...@sbcglobal.net> wrote:
> I would have expected, though, with build.sysclasspath=last that the
> JDK 1.3 classes would be there first.
No, because the JDK 1.4 classes are on the bootclasspath.
> The other route is to split up the build using the gump_split_*
> targets. Is it possible to just add multiple <ant>s underneath the
> <project> tag?
No, the way to go is to have seven projects in db-derby.xml, each one
depending on the former split and only the last one publishing the
jars. We also need to ensure that JDK 1.3's rt.jar is on the
bootclasspath, which may or may not cause different problems later.
If I find time, I'll take a stab at it today (which has just started
for me).
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Andrew McIntyre <fu...@sbcglobal.net>.
On Jan 26, 2005, at 12:44 AM, Stefan Bodewig wrote:
> I don't think this is going to work with JDK 1.4's rt.jar on the
> bootclasspath. We could give it a try, even though
> build.sysclasspath=last is not strictly the Gump way (you can swap in
> your own dependency libs that way).
Well, it didn't work. The current error is:
compile:
[javac] Compiling 147 source files to
/home/gump/workspaces2/public/workspace/db-derby/classes
[javac]
/home/gump/workspaces2/public/workspace/db-derby/java/engine/org/
apache/derby/impl/jdbc/EmbedConnection.java:89:
org.apache.derby.impl.jdbc.EmbedConnection is not abstract and does not
override abstract method setSavepoint(java.lang.String) in
java.sql.Connection
[javac] public class EmbedConnection implements java.sql.Connection
[javac] ^
[javac] 1 error
This is what I would expect to see if JDK 1.4's java.sql.Connection is
on the classpath before JDK 1.3's Connection. I would have expected,
though, with build.sysclasspath=last that the JDK 1.3 classes would be
there first.
The other route is to split up the build using the gump_split_*
targets. Is it possible to just add multiple <ant>s underneath the
<project> tag? e.g.:
<ant target="gump_split_1"/>
<ant target="gump_split_2">
<property name="build.sysclasspath" value="last"/>
<property name="java13compile.classpath"
project="java-runtime-1.3"
reference="jarpath"/>
</ant>
<ant target="gump_split_3"/>
<ant target="gump_split_4">
<property name="build.sysclasspath" value="last"/>
<property name="java13compile.classpath"
project="java-runtime-1.3"
reference="jarpath"/>
</ant>
<ant target="gump_split_5"/>
<ant target="gump_split_6">
<property name="build.sysclasspath" value="last"/>
<property name="java13compile.classpath"
project="java-runtime-1.3"
reference="jarpath"/>
</ant>
<ant target="gump_split_7"/>
Or is it necessary to break it out into separate <project>s?
Thanks for your help,
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Stefan Bodewig <bo...@apache.org>.
On Wed, 26 Jan 2005, Andrew McIntyre <fu...@sbcglobal.net> wrote:
> On Jan 25, 2005, at 2:04 AM, Stefan Bodewig wrote:
>
>> Ideally we'd build everything except the JDBC 2.0 stuff using
>> Gump's default. And build the JDBC 2.0 stuff with JDK 1.3's rt.jar
>> on the bootclasspath.
>
> The easiest way to achieve this would be to set the property j13lib
> to the location of the JDK 1.3 jar, and build with
> build.sysclasspath=last.
I don't think this is going to work with JDK 1.4's rt.jar on the
bootclasspath. We could give it a try, even though
build.sysclasspath=last is not strictly the Gump way (you can swap in
your own dependency libs that way).
I'll look into it after my current module-housekeeping job is through
...
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Andrew McIntyre <fu...@sbcglobal.net>.
On Jan 25, 2005, at 2:04 AM, Stefan Bodewig wrote:
> Ideally we'd build everything except the JDBC 2.0 stuff using Gump's
> default. And build the JDBC 2.0 stuff with JDK 1.3's rt.jar on the
> bootclasspath.
The easiest way to achieve this would be to set the property j13lib to
the location of the JDK 1.3 jar, and build with
build.sysclasspath=last. I don't know if this is currently possible,
but I'm guessing no.
> Is there any sensible split of targets in the build file in order to
> achieve that?
So, I made a first pass at this and it come out to seven splits. In the
main derby build.xml there are now 7 new targets:
gump_split_1: builds everything up to internal api JDBC 2.0 interfaces
gump_split_2: builds internal api JDBC 2.0 interfaces
gump_split_3: builds up to implementations of JDBC 2.0 interfaces
gump_split_4: builds implementations of JDBC 2.0 interfaces
gump_split_5: builds external api up to JDBC 2.0 interfaces
gump_split_6: builds external api classes for JDBC 2.0
gump_split_7: builds everything else.
So, gump_split_2, 4, and 6 should be built with JDK 1.3's rt.jar, the
rest can be built with JDK 1.4's rt.jar. They should be built in order.
Also, I just realized that all of these need to be built with the
property sane=false, which creates a build with all optimizations
turned on.
I will try in the future to condense these to a smaller number of
targets, but I don't currently know if this is possible. With these
targets, though, i think it might be possible to build derby with gump.
Please let me know if there is more I can do.
Thanks,
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 24 Jan 2005, Andrew McIntyre <fu...@sbcglobal.net> wrote:
> On Jan 24, 2005, at 3:32 AM, Stefan Bodewig wrote:
>
>> Is there a work-around for this? I mean other than "install JDK
>> 1.3's rt.jar somewhere on brutus.apache.org". If not, well, then
>> we'll just do that.
>
> Unfortunately, I cannot think of another workaround. There is no
> substitute for the JDK 1.3 runtime classes in this instance.
OK.
We now do have a JDK 1.3 on brutus as well.
Ideally we'd build everything except the JDBC 2.0 stuff using Gump's
default. And build the JDBC 2.0 stuff with JDK 1.3's rt.jar on the
bootclasspath.
Is there any sensible split of targets in the build file in order to
achieve that? Something like splitting it into three projects, the
first builds everything leading up to the JDBC 2.0 build, the second
does only the JDBC 2.0 build and the third does the rest?
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Andrew McIntyre <fu...@sbcglobal.net>.
On Jan 24, 2005, at 3:32 AM, Stefan Bodewig wrote:
> Is there a work-around for this? I mean other than "install JDK 1.3's
> rt.jar somewhere on brutus.apache.org". If not, well, then we'll just
> do that.
Unfortunately, I cannot think of another workaround. There is no
substitute for the JDK 1.3 runtime classes in this instance.
> It's about noon here in Germany ;-)
It's nearly 4am in San Francisco. ;-)
cheers,
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Stefan Bodewig <bo...@apache.org>.
On Mon, 24 Jan 2005, Samuel Andrew McIntyre
<fu...@nonintuitive.com> wrote:
> That is a complicated question. Currently the build process for
> Derby expects multiple versions of the runtime classes to be
> accessible (but not in the classpath simultaneously).
I don't think we can do so in Gump easily. We currently don't have a
JDK 1.3 installed on the machine running Gump, for example.
Is there a work-around for this? I mean other than "install JDK 1.3's
rt.jar somewhere on brutus.apache.org". If not, well, then we'll just
do that.
> Please allow me to pick this up tomorrow, at a more forgiving
> hour. :-)
It's about noon here in Germany ;-)
Cheers
Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Samuel Andrew McIntyre <fu...@nonintuitive.com>.
On Jan 24, 2005, at 12:49 AM, Stefan Bodewig wrote:
> Seems you are using a
> different address for sending than you've subscribed with.
That does explain some of my problems. That will hopefully be fixed on
my end going forward. :)
> By now you can rely on Gump running on JDK 1.4+.
>
> Does the build process always build against the different runtime,
> even if they are not present at all? How? Do you ship with JDBC
> interface classes for them?
That is a complicated question. Currently the build process for Derby
expects multiple versions of the runtime classes to be accessible (but
not in the classpath simultaneously). The compilation classpath is set
in the buildfiles explicitly to reflect which version of the JDBC
interfaces need to be accessible at any given time. Also, derby.jar
ships with multiple versions of the same interface and the correct
version is chosen at runtime.
To elaborate:
Short answer: The build process requires that both JDBC 2.0 (JDK 1.3)
and JDBC 3.0 (JDK 1.4) versions of certain interfaces be present at
specific points in the build process in order to build all the
necessary classes needed for the product jar file. The build process is
not currently able to handle the situation where one of those
interfaces is not accessible. The classes for both JDBC 2.0 and JDBC
3.0 implementations are shipped in the same product jar file, and the
correct classes are chosen at runtime depending on the version of Java
running Derby at that moment.
Long answer: There are implementations of both the JDBC 2.0 and JDBC
3.0 interfaces in Derby. These public implementations use internal APIs
to perform the work that is requested through the public
implementations. At the moment, the JDBC 3.0 implementations are
extensions of the JDBC 2.0 implementations, which means that the JDBC
2.0 implementations must be correctly compiled before the JDBC 3.0
implementations. Also, because users expect Derby to be compatible with
both JDBC 2.0 and JDBC 3.0 at runtime, it is important to provide the
proper version of both JDBC interfaces at runtime. Which means
packaging all supported versions of those interfaces in the same jar
file.
...
Please allow me to pick this up tomorrow, at a more forgiving hour. :-)
andrew
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: derby build
Posted by Dalibor Topic <ro...@kaffe.org>.
Stefan Bodewig <bodewig <at> apache.org> writes:
> By now you can rely on Gump running on JDK 1.4+. I'm not sure which
> version of JDBC Kaffe ships with, though.
According to http://www.kaffe.org/~stuart/japi/htmlout/h-jdk14-classpath.html we
have all the methods & classes from java.sql and javax.sql form 1.4 implemented.
cheers,
dalibor topic
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org