Rick Hillegas wrote:
One thing that's puzzling to me is why the build is trying to compile
Sed.java (used by the old test harness) in the target that compiles
support for our junit harness. According to the build output, the
error is raised in the second javac block of junitcomponents. That
I have checked in some build logic which automatically sets the compiler
classpath properties. This is part of the work on DERBY-3117 and the
goal, ultimately, is to have a Derby build script which works out of
the box without any customizing of ant.properties.
In order to take advantage of
Rick Hillegas wrote:
I have checked in some build logic which automatically sets the
compiler classpath properties. This is part of the work on DERBY-3117
and the goal, ultimately, is to have a Derby build script which works
out of the box without any customizing of ant.properties.
In order
Vemund Ostgaard wrote:
Rick Hillegas wrote:
I have checked in some build logic which automatically sets the
compiler classpath properties. This is part of the work on DERBY-3117
and the goal, ultimately, is to have a Derby build script which
works out of the box without any customizing of
I tried it out in my sandbox Rick, and it worked fine except for one
thing that probably isn't related to your changes.
The first time I do ant all after having done ant clean or ant
clobber, the build fails when compiling
junitcomponents:
[javac] Compiling 1 source file to
Vemund Ostgaard wrote:
I tried it out in my sandbox Rick, and it worked fine except for one
thing that probably isn't related to your changes.
The first time I do ant all after having done ant clean or ant
clobber, the build fails when compiling
junitcomponents:
[javac] Compiling 1
Rick Hillegas [EMAIL PROTECTED] writes:
I have checked in some build logic which automatically sets the
compiler classpath properties. This is part of the work on DERBY-3117
and the goal, ultimately, is to have a Derby build script which works
out of the box without any customizing of
Knut Anders Hatlen wrote:
Rick Hillegas [EMAIL PROTECTED] writes:
I have checked in some build logic which automatically sets the
compiler classpath properties. This is part of the work on DERBY-3117
and the goal, ultimately, is to have a Derby build script which works
out of the box
Rick Hillegas wrote:
Over the next month, I would appreciate it if people could try out the
automatic property setting in their own environments and let me know if
something breaks. I would like this to be as solid as possible before
switching the default behavior.
I set the properties
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Over the next month, I would appreciate it if people could try out the
automatic property setting in their own environments and let me know
if something breaks. I would like this to be as solid as possible
before switching the default
Rick Hillegas wrote:
The place to add support for additional platforms/vms would be
trunk/java/build/org/apache/derbyPreBuild/PropertySetter.java The class
has a pretty extensive header comment explaining what the class
does--but please let me know if the header is unclear.
At line 207
Daniel John Debrunner wrote:
Rick Hillegas wrote:
The place to add support for additional platforms/vms would be
trunk/java/build/org/apache/derbyPreBuild/PropertySetter.java The
class has a pretty extensive header comment explaining what the class
does--but please let me know if the header
Rick Hillegas wrote:
Daniel John Debrunner wrote:
Rick Hillegas wrote:
The place to add support for additional platforms/vms would be
trunk/java/build/org/apache/derbyPreBuild/PropertySetter.java The
class has a pretty extensive header comment explaining what the class
does--but please let
Daniel John Debrunner wrote:
At line 207 (just after this code)
if ( j14lib != null ) { setClasspathFromLib( J14LIB, j14lib ); }
if ( j15lib != null ) { setClasspathFromLib( J15LIB, j15lib ); }
The wrong property names were being passed to setClasspathFromLib(),
they should be
Rick Hillegas [EMAIL PROTECTED] writes:
Knut Anders Hatlen wrote:
Rick Hillegas [EMAIL PROTECTED] writes:
I have checked in some build logic which automatically sets the
compiler classpath properties. This is part of the work on DERBY-3117
and the goal, ultimately, is to have a Derby
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Daniel John Debrunner wrote:
Rick Hillegas wrote:
The place to add support for additional platforms/vms would be
trunk/java/build/org/apache/derbyPreBuild/PropertySetter.java The
class has a pretty extensive header comment explaining what
Daniel John Debrunner wrote:
Daniel John Debrunner wrote:
At line 207 (just after this code)
if ( j14lib != null ) { setClasspathFromLib( J14LIB, j14lib ); }
if ( j15lib != null ) { setClasspathFromLib( J15LIB, j15lib ); }
The wrong property names were being passed to
Daniel John Debrunner wrote:
One question is why does this code need to be executed if I already have
j14lib and j15lib set in my ant.properties?
String jdkVendor = getProperty( JDK_VENDOR );
if ( JDK_APPLE.equals( jdkVendor ) ) { setForAppleJDKs(); }
18 matches
Mail list logo
