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 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, which I'm sure is correct behavior on the part of Ant. Can you use a striplinebreaks filter reader in your loadfile task? This would throw out any line feeds and should allow us to build derby without upgrading svn. Stefan - 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 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 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}/
Most trivial idea: ${changenumber} expands to a value that ends with a
new-line or a cariage-return new-line sequence. vmgump is Linux, this
could happen if the property gets read from a file that has extra
cariage returns (checked in binary on a Windows box, for example).
Other than that, a bug in Ant's trunk version? Can you try building
Ant for yourself and give it a try?
Stefan
-
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...)
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 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] - 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 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 the first one of a new section, which in turn makes the manifest invalid. Stefan - 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]
