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
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
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.
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
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
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.
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
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 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
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 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
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
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
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
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.
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
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
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 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 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 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 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
22 matches
Mail list logo
