db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ray Kiddy <kid...@apple.com>
Subject Re: building Derby on Mac OS X
Date Mon, 03 Jul 2006 05:51:53 GMT

On Jul 2, 2006, at 9:39 PM, Andrew McIntyre wrote:

> On 7/2/06, Ray Kiddy <kiddyr@apple.com> wrote:
>>
>> I tried to build derby on Mac OS X and I had issues that I had not
>> expected.
>>
>> I just wanted to report these for now and see it anyone has
>> suggestions on how to proceed. I am on a 10.4.7 system. The default
>> at this point is usually 1.5, but I set the default JVM back to 1.4.2
>> for the purposes of building derby.
>
> It is necessary do this to build Derby 10.1 on any platform. See the
> previous thread today concerning that. I thought that is was mentioned
> in the build instructions (BUILDING.txt), but maybe not.

You said:

	"However, only the JDK 1.4 and JDK 1.3 Java runtime libraries are  
needed to compile or run Derby."

This is different than saying that 1.3 and 1.4 are the only ones that  
work.

>
>> 1) </snip description of modifying the source/target attributes>
>
> This should not be necessary. Could you post the errors you received
> trying to build an unmodified source tree?

Sure. I will attach the log.


>
>> 2) There were methods missing from some of the java.sql classes. A
>> couple of the interfaces were not completely implemented. I put in
>> stubs so that derby will compile. I would not expect them to work,
>> though.
>
> This should not be the case. Could you also post these errors?

It said just that the classes were not abstract and did not implement  
all the required methods.

 From java/engine/org/apache/derby/impl/jdbc/EmbedConnection.java:

+    public void releaseSavepoint(Savepoint savepoint) throws  
java.sql.SQLException { }
+    public Savepoint setSavepoint() throws java.sql.SQLException  
{ return null; }
+    public Savepoint setSavepoint(String name) throws  
java.sql.SQLException { return null; }
+    public void rollback(Savepoint savepoint) throws  
java.sql.SQLException { }

You see that there methods are in the Connection interface, yes?  
There is no super-class of this class that might implement them.

AFAIK, if you are building against the 1.4.2 version of the classes,  
this is what you get.

>
>> 3) The code, as I checked it out, could not seem to find the
>> JVMInfo.J2SE_16 ivar. I see where this is defined, but I do not see
>> where the build system includes that class in the classpath of the
>> other build.xml files. I just changed the references to
>> JVMInfo.J2SE_16 to its value, 7.
>
> I see the change that you made was to a file in the client code. When
> the client code is built, the JVMInfo class, part of the engine,
> should already have been built and be present in the output directory.
> The compiler should pick it up from the output directory and not the
> classpath.

I did not do an "ant clobber" after every attempt. Maybe I should.  
Perhaps there is something indeterminate in the build if parts of it  
fail.

>
>> Obviously, these are not the solutions to the issues. Are there other
>> solutions already in progress? Has anyone else build Derby on a Tiger
>> Mac OS X system? I will include my diffs below. I will also put the
>> contents of my ~/ant.properties file here.
>
> I build on Mac OS X all the time without needing any source
> modifications, as it's my primary development platform.
>
> In case it helps, here's my ant.properties:
> ...
> j13lib=/System/Library/Frameworks/JavaVM.framework/Versions/1.3.1/ 
> Classes
> j14lib=/System/Library/Frameworks/JavaVM.framework/Versions/1.4.2/ 
> Classes
>
> java13compile.classpath=${j13lib}/classes.jar;${j13lib}/ui.jar;$ 
> {j13lib}/i18n.jar;${j13lib}/sunrsasign.jar;${javatools.dir}/jdbc2_0- 
> stdext.jar;${j14lib}/dt.jar
> java14compile.classpath=${j14lib}/classes.jar;${j14lib}/ui.jar;$ 
> {j14lib}/laf.jar;${j14lib}/sunrsasign.jar;${j14lib}/jsse.jar;$ 
> {j14lib}/jce.jar;${j14lib}/charsets.jar;${j14lib}/dt.jar
> deprecation=off
>
> compile.classpath=${java13compile.classpath}
> javatools.dir=${basedir}/tools/java
> javadoc.tool.jdk14=${java.home}/bin/javadoc
> ...
>

The setting of the compile.classpath variable was deliberate. That  
was to make it work.
> The main difference seems to be the setting of the compile.classpath
> variable. Try setting it equal to java13compile.classpath and let me
> know if that helps.
>

What version of the system are you running? Which java is your default?

Do you have this?

% java -version
java version "1.4.2_09"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_09-232)
Java HotSpot(TM) Client VM (build 1.4.2-54, mixed mode)
%

- ray

> cheers,
> andrew


I tried setting my default version to 1.3 and I get this:

compile:
     [javac] Compiling 11 source files to /Users/ray/Projects/derby/ 
classes
     [javac] /Users/ray/Projects/derby/java/shared/org/apache/derby/ 
shared/common/reference/JDBC20Translation.java:24: cannot access  
javax.transaction.xa.XAResource
     [javac] bad class file: /Users/ray/Projects/derby/tools/java/ 
geronimo-spec-jta-1.0.1B-rc4.jar(javax/transaction/xa/XAResource.class)
     [javac] class file has wrong version 48.0, should be 47.0
     [javac] Please remove or make sure it appears in the correct  
subdirectory of the classpath.
     [javac] import javax.transaction.xa.XAResource;
     [javac]                             ^
     [javac] 1 error


I tried setting my defualt to 1.4.2 and I get:

compile_impl_services:
     [javac] Compiling 3 source files to /Users/ray/Projects/derby/ 
classes
     [javac] /Users/ray/Projects/derby/java/engine/org/apache/derby/ 
impl/services/jce/JCECipherFactory.java:52: package javax.crypto does  
not exist
     [javac] import javax.crypto.KeyGenerator;
     [javac]                     ^
     [javac] /Users/ray/Projects/derby/java/engine/org/apache/derby/ 
impl/services/jce/JCECipherFactory.java:53: package javax.crypto does  
not exist
     [javac] import javax.crypto.SecretKey;
     [javac]                     ^
     [javac] /Users/ray/Projects/derby/java/engine/org/apache/derby/ 
impl/services/jce/JCECipherFactory.java:54: package javax.crypto does  
not exist
     [javac] import javax.crypto.SecretKeyFactory;
     [javac]                     ^
     [javac] /Users/ray/Projects/derby/java/engine/org/apache/derby/ 
impl/services/jce/JCECipherFactory.java:55: package javax.crypto.spec  
does not exist
     [javac] import javax.crypto.spec.DESKeySpec;
     [javac]                          ^
     [javac] /Users/ray/Projects/derby/java/engine/org/apache/derby/ 
impl/services/jce/JCECipherFactory.java:56: package javax.crypto.spec  
does not exist
     [javac] import javax.crypto.spec.SecretKeySpec;
     [javac]                          ^



Your second e-mail:

> 	From: 	  mcintyre.a@gmail.com
> 	Subject: 	Re: building Derby on Mac OS X
> 	Date: 	July 2, 2006 10:22:34 PM PDT
> 	To: 	  derby-user@db.apache.org
> 	Reply-To: 	  derby-user@db.apache.org
>
> So, I think that setting compile.classpath=${java14compile.classpath}
> is definitely the problem here, since I just tried that on my machine
> and the build breaks in similar ways to what you described.
>
> On 7/2/06, Ray Kiddy <kiddyr@apple.com> wrote:
>
>> The 1.3 JVM that is on the system
>> is deprecated. Really, it cannot be relied on for anything modern.
>>
>
> What the build is looking for is not the 1.3 JVM, but its class
> libraries. Derby currently maintains compatibility with JDK 1.3.1
> (JDBC 2.0), and so it needs to reference the class libraries to
> compile the classes necessary to run Derby on JDK 1.3.1. But, you
> should run Ant with a 1.4.2 JVM (for Derby 10.1 or earlier) or with
> 1.4.2, 1.5, or 1.6 (b86 or later) for Derby 10.2 / trunk in order to
> build.
>

I'll have to parse this out.

I have a feeling it may be possible to be more explicit about the  
version stuff going on here.

- ray

>
>> 1) The build seems to assume that the default JVM is 1.3, but then it
>> does not actually build if one uses that setting.
>>
>
> The lowest JVM level that Derby supports is 1.3.1, but you need to run
> Ant with a 1.4.2 or later JVM as mentioned above in order to build it.
> Perhaps this should be made more explicit in BUILDING.txt.
>
>
>> compile.classpath=${java14compile.classpath}
>>
>
> should be set to the java13compile.classpath so that the class
> libraries for JDK 1.3.1 are picked up for the compilations that
> require them. From BUILDING.txt section 2.2:
>
> (1) Derby build environment requires you to install two levels of
>    Java Development Kit (JDK) - 1.3.x and 1.4.x as Derby is designed
>    to work in JDK1.3.x (JDBC 2.0) and JDK 1.4.x (JDBC 3.0)
>    environments. The Derby build is set up such that that most of
>    the code is compiled against JDK 1.3.x libraries so that no
>    dependencies on JDK 1.4.x classes exist, except for the code
>    that only runs in JDK1.4.x. In addition Derby's JDBC 2.0
>    implementation must compile against JDBC 2.0 class definitions
>    and the JDBC 3.0 implementation against JDBC 3.0 class
>    definitions.
>
> Conveniently, Mac OS X already has both 1.3.1 and 1.4.2 installed.
> Note that there are some other libraries that need to be downloaded to
> build a complete build, and these are mentioned in BUILDING.txt.
>
> Note that when building to target a J2ME environment, that
> compile.classpath should actually be set to reference the J2ME
> classes, and not the JDK 1.3.1 classes. This isn't your concern, but
> it's why there is a difference between compile.classpath and
> java13compile.classpath.
>
> So, try setting compile.classpath=${java13compile.classpath} in your
> ~/ant.properties and let me know if that solves your problem.
>
> thanks,
> andrew



Mime
View raw message