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
On Mon, 31 Oct 2005, Andrew McIntyre [EMAIL PROTECTED] wrote:
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,
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
. 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]
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 manifest task:
manifest
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
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
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
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
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
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
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
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
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,
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
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
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
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.
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.
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
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
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
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
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.
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
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
26 matches
Mail list logo
