Re: Failing project: derby-split-4
On 3/15/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: derby-split-4 = Dependees: 5 Affected : 6 Duration in state: 12 Gump metadata: sl4j.xml /snip What to do? Derby was recently changed to drop support for JDK 1.3, so the Derby build in Gump does not need to split around the classes that needed to be compiled with JDK 1.3. I've removed the split targets and replaced them with the normal Derby top-level build target 'all'. I'll keep an eye on the next few builds to make sure it builds normally. cheers, andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Failure in derby-split-1
Just noticed this has been failing for a while. The failure is here: compile_reference: [javac] Compiling 10 source files to /x1/gump/public/workspace/db-derby/classes [javac] /x1/gump/public/workspace/db-derby/java/engine/org/apache/derby/iapi/reference/SQLState.java:29: package org.apache.derby.shared.common.reference does not exist [javac] org.apache.derby.shared.common.reference.SQLState [javac] ^ [javac] 1 error BUILD FAILED This looks like svn did not properly update some files. The file that is missing exists in the source tree here: http://svn.apache.org/repos/asf/db/derby/code/trunk/java/shared/org/apache/derby/shared/common/reference/ Maybe those new files didn't update properly? Perhaps the pointers to the various source directories in tools/ant/properties/dirs.properties didn't update? Maybe there's something in the metadata I need to change to find the new files? Not sure what's going on, but I'll be glad to help if someone could take a look and make sure that the new files in java/shared are there. Thanks! andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Failure in derby-split-1
On 2/17/06, Bill Barker [EMAIL PROTECTED] wrote: I can't check the files myself, but it's hard to believe that 'svn up' has been failing for this long. What I'd check is if 'ant gump_split_1' works. It's likely that the missing file simply needs to be added to what that target builds. You're right. I just noticed this and should have looked a little closer before sending mail. A new target that I thought was already included in gump_split_1 as a dependant needed to be added explicitly to gump_split_1. Fixed for the next gump build.' 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...)
On Nov 1, 2005, at 9:31 PM, Stefan Bodewig wrote: Can you use a striplinebreaks filter reader in your loadfile 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...)
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 exec task, is then read back in to a
property using Ant's loadfile 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...)
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...)
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...)
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 manifest task:
manifest file=${derby.jar.dir}/lists/smf.mf
attribute name=Bundle-Vendor value=Apache Software
Foundation/
attribute name=Bundle-Name value=Apache Derby ${major}.$
{minor}/
attribute name=Bundle-Version value=${major}.${minor}.$
{maint}.${changenumber}/
attribute name=Sealed value=true/
section name=org/apache/derby/impl/tools/sysinfo/
attribute name=Sealed value=false/
/section
..
/manifest
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]
Derby build (Re: BATCH: All dressed up, with nowhere to go...)
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 ... snip other failures *** G U M P [EMAIL PROTECTED]: Project derby (in module db-derby) failed snip other targets 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: BATCH: All dressed up, with nowhere to go...
On Aug 19, 2005, at 5:27 AM, [EMAIL PROTECTED] wrote: 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:770: The following error occurred while executing this line: /x1/gump/public/workspace/db-derby/build.xml:849: Invalid Manifest: /x1/gump/public/workspace/db-derby/jars/insane/lists/smf.mf I'm unable to reproduce this error myself. From the error, it would seem that Ant has generated a bad manifest file in the manifest task of the derbyjarwithoutosgi target, presumably by putting space between the other top-level attributes and the top-level Sealed attribute. Works for me in my view, though. Is this maybe an Ant issue? Or stale files hanging around somehow? Would it be possible to get access to the bad manifest to better understand the problem? Thanks, andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: BATCH: All dressed up, with nowhere to go...
On 8/15/05, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 11 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Module db-derby success, but with warnings. *** G U M P snip Work ended in a state of : Failed Elapsed: 6 secs Command Line: svn --quiet update --non-interactive db-derby [Working Directory: /usr/local/gump/public/workspace/cvs] - svn: REPORT request failed on '/repos/asf/!svn/vcc/default' svn: Cannot replace a directory from within This is due to Derby's recent graduation and move out of the incubator, along with its source tree, to live in the db part of the repository. I've attached a patch which updates the URLs (and adds repository/db-svn.xml), but I think someone is going to have to go to where the source is checked out on vmgump and 'svn switch' the source to the new URL. I think there may still be an error to deal with past that, but at least the source will resume updating properly. Thanks, andrew A repository\db-svn.xml M project\db-derby.xml - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: derby-split-2 (was: BATCH: All dressed up, with nowhere to go...)
Sorry for the delay here... On Jul 11, 2005, at 4:46 AM, [EMAIL PROTECTED] wrote: Dear Gumpmeisters, The following 11 notifys should have been sent *** G U M P [EMAIL PROTECTED]: Project derby-split-2 (in module db-derby) failed *** G U M P snip lots of gumping *** G U M P [EMAIL PROTECTED]: Project derby-split-2 (in module db-derby) failed To whom it may engage... Command Line: java -Djava.awt.headless=true -Xbootclasspath/p:/usr/ local/gump/public/workspace/xml-commons/java/external/build/xml- apis.jar:/usr/local/gump/public/workspace/xml-xerces2/java/build/ xercesImpl.jar org.apache.tools.ant.Main -Dgump.merge=/x1/gump/ public/gump/work/merge.xml -Ddeprecation=false - Dbuild.sysclasspath=last -Dempty=/usr/local/gump/packages/java- runtime-1.3/rt.jar -Dbuild.compiler=jikes gump_split_2 [Working Directory: /usr/local/gump/public/workspace/db-derby] CLASSPATH: /opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/ workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/ dist/lib/ant-apache-resolver.jar:/usr/local/gump/public/workspace/ ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/ lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant- launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant- nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/ usr/local/gump/public/workspace/jakarta-servletapi-5/jsr154/dist/ lib/servlet-api.jar:/usr/local/gump/public/workspace/jakarta-oro/ jakarta-oro-11072005.jar:/usr/local/gump/packages/javacc-3.1/bin/ lib/javacc.jar:/usr/local/gump/packages/java-runtime-1.3/rt.jar:/ usr/local/gump/packages/jce/jce-jdk13-116.jar:/usr/local/gump/ packages/jdbc2_0/jdbc2_0-stdext.jar:/usr/local/gump/packages/jta- spec1_0_1/jta-spec1_0_1.jar - [javac] 46. 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. This, and the other failures in derby-split-2, would appear to be the result of JDK 1.4 interfaces being on the classpath before the JDK 1.3 interfaces against which these specific classes are expected to be compiled. However, the classpath reported by Gump doesn't appear to have any JDK 1.4 classes on it, besides tools.jar. Also, I had a script which emulates the Derby build in Gump by building with just one JDK on the classpath for each split, and this script still compiles Derby successfully. Is it possible that a change to Gump (or Ant) was made that is causing JDK 1.4 (or higher) classes to appear on the compilation classpath before the JDK 1.3 classes which are needed for this compile? I realize there's a lot of change to Gump going on right now, but I thought I should at least let you know that this specific failure hadn't gone completely unnoticed. Please let me know if there's anything I can do to help resolve this problem. Thanks, andrew
Re: derby build
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
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
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: derby build
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
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
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 ants 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 projects? Thanks for your help, andrew - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: derby build
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
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
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]
derby build (was: BATCH: All dressed up, with nowhere to go...)
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. snip 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]
