You are viewing a plain text version of this content. The canonical link for it is here.
Posted to general@gump.apache.org by Andrew McIntyre <fu...@sbcglobal.net> on 2005/02/02 08:41:09 UTC
Re: derby build
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 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