JSR169 status update & build/ant question

[Daniel John Debrunner <dj...@debrunners.com>]

I have JSR169 basically working though there are a few bugs to be ironed
out. Currently running in this mode will print out a warning when Derby
is started that it is an experimental version. I'm going to keep that
warning until the bugs are fixed.

The JDBC for JSR169 objects are part of an optional build target that
requires J2ME/CDC/Foundation 1.0 jars and JSR169 jar, see instructions
below.

In order to run in this environment these two module entries are needed
in modules.properties

# J2ME DataValueFactory, DECIMAL support without BigDecimal
derby.module.dvfJ2ME=org.apache.derby.iapi.types.CDCDataValueFactory

# J2ME/JSR169 JDBC driver implementation
derby.module.jdbcJ2ME=org.apache.derby.jdbc.Driver169
derby.env.classes.jdbcJ2ME=org.apache.derby.jdbc.Driver169


The question is how to deal with the second one Driver169, which is a
part of the optional target. The first is fine because it is part of the
regular build since it has no dependency on JSR169 libraries.

The issue is how to ensure no errors appear when running Derby having
*not* built the optional target. The above forms works fine when running
Derby out of the classes directory because the derby.env.classes line
means only load the associated module if the classes in this property
are loadable. E.g. for the encryption module it specifies that
javax.crypto.SecretKey must be loadable. In this JSR169 case I'm making
the module depend on itself which stops the error displayed by Derby if
a module class cannot be loaded. The problem with this approach is that
the jar build process breaks because it expects every module to exist so
that it can perform dependency checking on it.

The solutions are:

1) modify the dependency checker to skip modules that cannot be loaded
and have a dependency on themselves

2) Make the optional engine_169_opt target also modify the
modules.properties to add just
derby.module.jdbcJ2ME=org.apache.derby.jdbc.Driver169


I'm tending towards 1) because that's the code I know, but maybe the ant
approach is easier, but how do you ensure the line doesn't get added
multiple times?

Dan.


Building JSR169 optional components
-----------------------------------

1) Add an entry to your ant.properties for Derby, setting a JSR169
compile path

jsr169compile.classpath=<path of foundation 1.0 jars and JSR169 jars>

E.g. here is my setting for IBM's WCTME 5.7

jsr169compile.classpath=C:/wctme5.7/ive/lib/jclFoundation10/classes.zip;C:/wctme5.7/ive/lib/jdbc.jar

2) Build Derby as normal

3) Execute the optional target engine_169_opt

e.g.
ant engine_169_opt

Re: JSR169 status update & build/ant question

[Andrew McIntyre <mc...@gmail.com>]

On Jun 2, 2005, at 10:18 AM, Daniel John Debrunner wrote:

> 2) Make the optional engine_169_opt target also modify the
> modules.properties to add just
> derby.module.jdbcJ2ME=org.apache.derby.jdbc.Driver169

The easiest way is to do something similar to how splitmessages  
targets are handled, or ClassSizeCatalog generation. You have one  
target that performs the necessary action - in this case, a  
<replace>, <replaceregexp>, or <concat> task which performs the  
necessary edit on modules.properties in the output dir - and then  
<touch>s a file, usually in the same location preferably with a  
similar name, e.g. modules.done. This target depends on a target that  
checks for the existence of that file and sets a property if it  
exists, and the execution of the original argument is dependent on  
that new property not being set. You could also set a property - in  
my example below called jsr169.available - if there is a particular  
resource (jar file) or classname that should be available for your  
jsr169 support to compile.

<target name="jsr169_module_edit"  
depends="checkmoduleprops,checkjsr169" unless="modules.uptodate"  
if="jsr169.available">

   <!-- tasks for modifying modules.properties go here -->

<touch file="${out.dir}/${derby.dir}/modules.done"/>

</target>

<target name="checkmoduleprops">
   <condition property="modules.uptodate">
     <available file="${out.dir}/${derby.dir}/modules.done"/>
   </condition>
</target>

<target name="checkjsr169">
   <condition property="jsr169.available">
     <!-- check Ant docs for <available> for the appropriate entry  
here -->
   </condition>
</target>

Obviously, this should come in the build some time after  
modules.properties has been copied to ${out.dir}. When running clean  
or clobber, the .done file and the .properties file are both removed,  
which will cause the copy and edit to be performed at the time of the  
next build.

andrew