Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)

[Andrew McIntyre]

On Nov 1, 2005, at 9:31 PM, Stefan Bodewig wrote:


Can you use a  filter reader in your  task?


Definitely. I hadn't thought of that. Checked in, should build  
tomorrow. Thanks again, Stefan!


andrew

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)

[Stefan Bodewig]

On Mon, 31 Oct 2005, Andrew McIntyre <[EMAIL PROTECTED]> wrote:

> This output, recorded to a file using the output attribute of an Ant
>  task, is then read back in to a property using Ant's
>  task. Ant diligently includes the newline as a part of
> the property read in from the file, which I'm sure is correct
> behavior on the part of Ant.

Can you use a  filter reader in your  task?
This would throw out any line feeds and should allow us to build derby
without upgrading svn.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)

[Andrew McIntyre]

On Oct 31, 2005, at 12:12 AM, Andrew McIntyre wrote:

it turns out that it's a subversion problem, not an Ant or platform  
issue. The problem is that 'svnversion -n .' is returning a value  
that contains a newline when the directory whose version you are  
getting is 'exported,' when it should not be adding a newline.


I'll need to follow up with the subversion folks. Thanks for all  
the help from the gumpers!


FYI, fixed in Subversion 1.2.x with revision 10987 to Subversion.  
Which means, of course, that it exists with Subversion 1.1.4 which is  
currently in use with Gump. An upgrade to Subversion 1.2.x should fix  
the Derby build problem.


cheers,
andrew

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)

[Andrew McIntyre]

On Oct 29, 2005, at 6:31 AM, Stefan Bodewig wrote:


I can't promise to find time to do more research


No worries, I got it. :-)


Most trivial idea: ${changenumber} expands to a value that ends with a
new-line or a cariage-return new-line sequence.


This guess is correct, and it turns out that it's a subversion  
problem, not an Ant or platform issue. The problem is that  
'svnversion -n .' is returning a value that contains a newline when  
the directory whose version you are getting is 'exported,' when it  
should not be adding a newline. (FWIW, i think the problem is at  
svnversion's main.c, line 287.) This output, recorded to a file using  
the output attribute of an Ant  task, is then read back in to a  
property using Ant's  task. Ant diligently includes the  
newline as a part of the property read in from the file, which I'm  
sure is correct behavior on the part of Ant. Go Ant! :-D  When the  
property is later added to the manifest, it includes the newline,  
which causes the manifest to be invalid.


I'll need to follow up with the subversion folks. Thanks for all the  
help from the gumpers!


andrew


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)

[Stefan Bodewig]

On Wed, 26 Oct 2005, Andrew McIntyre <[EMAIL PROTECTED]> wrote:

> That's what I suspected, but any idea why Ant would do that on
> vmgump, but not elsewhere?

I can't promise to find time to do more research

> Here's the first few lines of the  task:
> 
>  
>
>
>

Most trivial idea: ${changenumber} expands to a value that ends with a
new-line or a cariage-return new-line sequence.  vmgump is Linux, this
could happen if the property gets read from a file that has extra
cariage returns (checked in binary on a Windows box, for example).

Other than that, a bug in Ant's trunk version?  Can you try building
Ant for yourself and give it a try?

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)

[Andrew McIntyre]

On Oct 27, 2005, at 7:19 AM, Leo Simons wrote:


Hi andrew,

Don't really understand the problem but I've put the db-derby dir from
vmgump at

  http://vmgump.apache.org/derby-gump-snapshot.tgz

please holler when we can remove it.


I've got the file, so you can go ahead and remove it.

Thanks much, Leo!

andrew

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)

[Leo Simons]

Hi andrew,

Don't really understand the problem but I've put the db-derby dir from
vmgump at

  http://vmgump.apache.org/derby-gump-snapshot.tgz

please holler when we can remove it.

cheers!

Leo

On Tue, Oct 25, 2005 at 03:11:01PM -0700, Andrew McIntyre wrote:
> Just noticed that this is still failing. I am unable to reproduce the
> problem. Please see my previous mail concerning this problem. It would
> appear on the surface to be an issue with how Ant generates the
> manifest file in the derbyjarwithoutosgi target.  Is there any way
> that I can get access to the manifest file in the zone where gump is
> run to compare with a copy generated outside of the gump run?
> 
> cheers,
> andrew
> 
> 
> On 10/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > *** G U M P
> > ...
> > [EMAIL PROTECTED]: Project derby (in module db-derby) failed
> >...
> >  other failures
> > *** G U M P
> > [EMAIL PROTECTED]: Project derby (in module db-derby) failed
> > 
> >
> > derbyjarwithoutosgi:
> >   [jar] Building jar: 
> > /x1/gump/public/workspace/db-derby/jars/insane/derby.jar
> >   [jar] Manifest is invalid: Manifest sections should start with a 
> > "Name" attribute and not "Sealed"
> >
> > BUILD FAILED
> > /x1/gump/public/workspace/db-derby/build.xml:775: The following error 
> > occurred while executing this line:
> > /x1/gump/public/workspace/db-derby/build.xml:854: Invalid Manifest: 
> > /x1/gump/public/workspace/db-derby/jars/insane/lists/smf.mf
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)

[Andrew McIntyre]

On Oct 26, 2005, at 9:22 PM, Stefan Bodewig wrote:


At least on vmgump there is an empty line in smf.mf between
Bundle-Version in the main section and Sealed: true.  This line makes
the Sealed attribute the first one of a new section, which in turn
makes the manifest invalid.


That's what I suspected, but any idea why Ant would do that on  
vmgump, but not elsewhere?


Here's the first few lines of the  task:


  
  
  




  

..


What I get is:

Manifest-Version: 1.0
Ant-Version: Apache Ant 1.6.2
Created-By: 1.4.2
Bundle-Vendor: Apache Software Foundation
Bundle-Name: Apache Derby 10.2
Bundle-Version: 10.2.0.233223
Sealed: true

Name: org/apache/derby/impl/tools/sysinfo/
Sealed: false
..

Any clues? Maybe an old, invalid manifest hanging around that's not  
being overwritten?


Thanks,
andrew


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Derby build (Re: BATCH: All dressed up, with nowhere to go...)

[Stefan Bodewig]

On Tue, 25 Oct 2005, Andrew McIntyre <[EMAIL PROTECTED]> wrote:

> Just noticed that this is still failing. I am unable to reproduce
> the problem.

At least on vmgump there is an empty line in smf.mf between
Bundle-Version in the main section and Sealed: true.  This line makes
the Sealed attribute the first one of a new section, which in turn
makes the manifest invalid.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Derby build (Re: BATCH: All dressed up, with nowhere to go...)

[Andrew McIntyre]

Just noticed that this is still failing. I am unable to reproduce the
problem. Please see my previous mail concerning this problem. It would
appear on the surface to be an issue with how Ant generates the
manifest file in the derbyjarwithoutosgi target.  Is there any way
that I can get access to the manifest file in the zone where gump is
run to compare with a copy generated outside of the gump run?

cheers,
andrew


On 10/25/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> *** G U M P
> ...
> [EMAIL PROTECTED]: Project derby (in module db-derby) failed
>...
>  other failures
> *** G U M P
> [EMAIL PROTECTED]: Project derby (in module db-derby) failed
> 
>
> derbyjarwithoutosgi:
>   [jar] Building jar: 
> /x1/gump/public/workspace/db-derby/jars/insane/derby.jar
>   [jar] Manifest is invalid: Manifest sections should start with a "Name" 
> attribute and not "Sealed"
>
> BUILD FAILED
> /x1/gump/public/workspace/db-derby/build.xml:775: The following error 
> occurred while executing this line:
> /x1/gump/public/workspace/db-derby/build.xml:854: Invalid Manifest: 
> /x1/gump/public/workspace/db-derby/jars/insane/lists/smf.mf

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Stefan Bodewig]

On Thu, 10 Feb 2005, Andrew McIntyre <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Andrew McIntyre]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Stefan Bodewig]

On Wed, 9 Feb 2005, Samuel Andrew McIntyre
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Samuel Andrew McIntyre]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Andrew McIntyre]

On Feb 9, 2005, at 2:22 AM, Stefan Bodewig wrote:
Woohoo!

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  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

[Stefan Bodewig]

On Tue, 8 Feb 2005, Samuel Andrew McIntyre
<[EMAIL PROTECTED]> wrote:

> I will turn off the deprecation flag for now in the splits that use
> Jikes.

Woohoo!



Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Stefan Bodewig]

On Tue, 8 Feb 2005, Samuel Andrew McIntyre
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Samuel Andrew McIntyre]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Samuel Andrew McIntyre]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Stefan Bodewig]

On Fri, 4 Feb 2005, Samuel Andrew McIntyre
<[EMAIL PROTECTED]> wrote:

> Actually, in order to prevent Ant from putting the runtime libraries
> on jikes' classpath, we currently set the bootclasspath attribute on
> all  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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Samuel Andrew McIntyre]

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 
 tasks to ${empty}, which is the location of an empty jar file. 
Is this what you mean? e.g.:


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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Stefan Bodewig]

On Thu, 3 Feb 2005, Samuel Andrew McIntyre
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Samuel Andrew McIntyre]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Andrew McIntyre]

On Feb 2, 2005, at 2:43 AM, Stefan Bodewig wrote:
On Tue, 1 Feb 2005, Andrew McIntyre <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Stefan Bodewig]

On Tue, 1 Feb 2005, Andrew McIntyre <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Stefan Bodewig]

On Tue, 1 Feb 2005, Andrew McIntyre <[EMAIL PROTECTED]> 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 s underneath the
>  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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Andrew McIntyre]

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 s underneath the  
 tag? e.g.:



  
  
reference="jarpath"/>



  
  
reference="jarpath"/>



  
  
reference="jarpath"/>



Or is it necessary to break it out into separate s?
Thanks for your help,
andrew
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Stefan Bodewig]

On Wed, 26 Jan 2005, Andrew McIntyre <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Stefan Bodewig]

On Wed, 26 Jan 2005, Samuel Andrew McIntyre
<[EMAIL PROTECTED]> wrote:

> resending with the current account. *sigh*

I've just "allowed" your other address to post as well.

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Samuel Andrew McIntyre]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Andrew McIntyre]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Stefan Bodewig]

On Mon, 24 Jan 2005, Andrew McIntyre <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Dalibor Topic]

Stefan Bodewig  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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Andrew McIntyre]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Stefan Bodewig]

On Mon, 24 Jan 2005, Samuel Andrew McIntyre
<[EMAIL PROTECTED]> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Samuel Andrew McIntyre]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: derby build

[Stefan Bodewig]

On Sun, 23 Jan 2005, Andrew McIntyre <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] 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  elements pointing to those interfaces and
have derby depend on them.

Cheers

Stefan

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

derby build (was: BATCH: All dressed up, with nowhere to go...)

[Andrew McIntyre]

On Jan 22, 2005, at 4:12 AM, [EMAIL PROTECTED] wrote:
*** G U M P
[EMAIL PROTECTED]: Project derby (in module db-derby) failed
First, many thanks Stephan for cleaning up my attempt at a project file  
for derby! I'll be glad to help get the Derby build going, just let me  
know how. It's taken me a while to get subscribed to [EMAIL PROTECTED] due  
to mail client problems on my end.


compile_iapi_jdbc_jdbc2:
[javac] Compiling 3 source files to  
/home/gump/workspaces2/public/workspace/db-derby/classes
[javac]  
/home/gump/workspaces2/public/workspace/db-derby/java/engine/org/ 
apache/derby/iapi/jdbc/BrokeredPreparedStatement.java:34:  
org.apache.derby.iapi.jdbc.BrokeredPreparedStatement is not abstract  
and does not override abstract method getParameterMetaData() in  
java.sql.PreparedStatement
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. One possible solution to the error  
referenced above would be to pass in those two properties with their  
proper values and run Ant with build.sysclasspath set to 'last'. But, I  
don't know if that is possible.

Thanks again for your help,
andrew
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]