You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by John Embretsen <Jo...@Sun.COM> on 2005/11/14 18:00:18 UTC
Building jars from 10.1.2.1 source fails: "Manifest is invalid"
Hi all,
has anyone tried to build the Derby jars based on the 10.1.2.1 (10.1.2
Release Candidate #2) source code archive? (We are supposed to be able
to do this, right?)
I downloaded db-derby-10.1.2.1-src.tar.gz from
http://people.apache.org/~kmarsden/derby10.1.2.1.330608/ and extracted
the archive.
Running "ant all" goes just fine - however, "ant buildjars" fails,
saying that the jars/sane/lists.smf.mf manifest is invalid. Ant
complains that 'Manifest sections should start with a "Name" attribute
and not "Sealed"' (see attachment "ant_buildjars_error.txt").
I compared the smf.mf of the 10.1.2.1 "build" with the same file in my
subversion repository, and the only difference was that the 10.1.2.1
manifest has an extra blank line between "Bundle-Version" and the first
"Sealed: true" attribute in the manifest, which apparently causes the
failure (see attachment "smf.mf").
The lonely "Sealed: true" attribute is obviously supposed to be in the
"main section" of the manifest.
http://java.sun.com/j2se/1.4.2/docs/guide/jar/jar.html states that
"No attribute in this section can have its name equal to "Name". This
section is terminated by an empty line." Thus, the extra empty line is
causing the failure.
A google search led me to a thread in the mailing list archive of Apache
Gump: http://tinyurl.com/742ln.
It seems that Andrew has come across the same build error fairly
recently, and that this is/was a subversion problem.
So, Andrew, any ideas why this error appears when I try to build the
jars based on the code from the 10.1.2.1 source archive?
My build environment:
Solaris 10 (x86)
ANT_HOME=/usr/local/share/java/apache-ant-1.6.2
PATH=${ANT_HOME}/bin:$PATH
JAVA_HOME=/usr/local/java/jdk1.4
ant.properties:
j14lib=/usr/local/java/jdk1.4/jre/lib
j13lib=/usr/local/java/jdk1.3/jre/lib
proceed=false
sane=true
--
John
Re: Building jars from 10.1.2.1 source fails: "Manifest is invalid"
Posted by John Embretsen <Jo...@Sun.COM>.
Monday, November 14, 2005, 9:01:38 PM, Andrew McIntyre wrote:
> No, it is the version of Subversion of the user running the buildjars
> target from the source distribution that matters, not the person
> packaging the release. The manifest is generated by Ant at the time
> that the buildjars target is run, not when the source distribution is
> created.
> So, in this case, yes, the version of Subversion that you are running
> is what makes the difference, and if you upgraded your Subversion to
> 1.2.0 or later, you would be able to run the buildjars target as well
> as if you had applied the patch that I sent.
> andrew
I know you are right - I tried the same thing on a machine which has
Subversion 1.2.3 installed, and it worked without applying the patch. It
just seemed a little "illogical" to me at first, because I never
explicitly associated svn with the source code in any way, I just
downloaded and extracted an archive and executed Ant.
I still don't quite understand how and why subversion is used in this
case. I don't know a lot about the inner workings of Ant, Subversion or
the Derby release- and build processes, so please bear with me. Would
you like to explain this briefly (if possible) to me? (I.e. the "how"
and "why" part, not the inner workings part ;) )
I assumed it has something to do with how the changenumber.properties file
is generated.
Thanks!
--
John
Re: Building jars from 10.1.2.1 source fails: "Manifest is invalid"
Posted by Andrew McIntyre <mc...@gmail.com>.
On Nov 14, 2005, at 11:52 AM, John Embretsen wrote:
> I am using Subversion 1.1.4, but this should not matter in this
> case, should it?
> I mean, I guess it is the subversion version of the person doing
> the release
> packaging (in this case Kathey, right?) that matters, or am I
> misunderstanding
> something here?
No, it is the version of Subversion of the user running the buildjars
target from the source distribution that matters, not the person
packaging the release. The manifest is generated by Ant at the time
that the buildjars target is run, not when the source distribution is
created.
So, in this case, yes, the version of Subversion that you are running
is what makes the difference, and if you upgraded your Subversion to
1.2.0 or later, you would be able to run the buildjars target as well
as if you had applied the patch that I sent.
andrew
Re: Building jars from 10.1.2.1 source fails: "Manifest is invalid"
Posted by John Embretsen <Jo...@Sun.COM>.
Monday, November 14, 2005, 7:33:51 PM CET, Andrew McIntyre wrote:
> On Nov 14, 2005, at 9:00 AM, John Embretsen wrote:
>> has anyone tried to build the Derby jars based on the 10.1.2.1 (10.1.2
>> Release Candidate #2) source code archive? (We are supposed to be able
>> to do this, right?)
>>
>> A google search led me to a thread in the mailing list archive of
>> Apache
>> Gump: http://tinyurl.com/742ln.
>> It seems that Andrew has come across the same build error fairly
>> recently, and that this is/was a subversion problem.
>>
>> So, Andrew, any ideas why this error appears when I try to build the
>> jars based on the code from the 10.1.2.1 source archive?
> Yes, there is a problem with svnversion in subversion 1.1.x and
> earlier that causes an additional carriage return to be appended to
> directories that are reported as 'exported', even when run with the -
> n option. The property ${changenumber} which contains the version
> reported by subversion then contains an additional carriage return,
> which in turn breaks the manifest file format by setting the top-
> level Sealed attribute apart from the rest of the top-level
> attributes as you noted.
> I checked in a fix to the trunk so that Gump could continue to run.
> It's a rather simple patch, which you could apply to the build.xml
> from the source distribution, attached to the end of this mail.
Excellent, I tried your patch (i.e., I added the <striplinebreaks> filter reader
to the top-level build.xml manually), and ant buildjars now works.
> This problem has been fixed in Subversion 1.2.0 and above. Upgrading
> to the latest subversion will also remedy the problem. For this
> reason, I would consider it a non-showstopper for holding up the
> 10.1.2.1 release, but I will merge the fix over to the 10.1 branch
> for future releases.
Yes, it would be unfortunate if this is considered a showstopper for the release
(still, it is too bad I didn't try this while the vote was still active), but I
have one question:
I am using Subversion 1.1.4, but this should not matter in this case, should it?
I mean, I guess it is the subversion version of the person doing the release
packaging (in this case Kathey, right?) that matters, or am I misunderstanding
something here?
--
John
> andrew
> Index: build.xml
> ===================================================================
> --- build.xml (revision 330289)
> +++ build.xml (revision 330290)
> @@ -700,9 +700,13 @@
> <property name="derby.jar.topdir" value="${basedir}/jars"/>
> <mkdir dir="${derby.jar.dir}"/>
> <mkdir dir="${derby.jar.dir}/lists"/>
> - <loadfile srcFile="${basedir}/changenumber.properties"
> + <loadfile srcFile="${basedir}/changenumber.properties"
> failonerror="false"
> - property="changenumber"/>
> + property="changenumber">
> + <filterchain>
> + <striplinebreaks/>
> + </filterchain>
> + </loadfile>
> <condition property="changenumber" value="???">
> <not>
> <isset property="changenumber"/>
Re: Building jars from 10.1.2.1 source fails: "Manifest is invalid"
Posted by Andrew McIntyre <mc...@gmail.com>.
On Nov 14, 2005, at 9:00 AM, John Embretsen wrote:
> has anyone tried to build the Derby jars based on the 10.1.2.1 (10.1.2
> Release Candidate #2) source code archive? (We are supposed to be able
> to do this, right?)
>
> A google search led me to a thread in the mailing list archive of
> Apache
> Gump: http://tinyurl.com/742ln.
> It seems that Andrew has come across the same build error fairly
> recently, and that this is/was a subversion problem.
>
> So, Andrew, any ideas why this error appears when I try to build the
> jars based on the code from the 10.1.2.1 source archive?
Yes, there is a problem with svnversion in subversion 1.1.x and
earlier that causes an additional carriage return to be appended to
directories that are reported as 'exported', even when run with the -
n option. The property ${changenumber} which contains the version
reported by subversion then contains an additional carriage return,
which in turn breaks the manifest file format by setting the top-
level Sealed attribute apart from the rest of the top-level
attributes as you noted.
I checked in a fix to the trunk so that Gump could continue to run.
It's a rather simple patch, which you could apply to the build.xml
from the source distribution, attached to the end of this mail.
This problem has been fixed in Subversion 1.2.0 and above. Upgrading
to the latest subversion will also remedy the problem. For this
reason, I would consider it a non-showstopper for holding up the
10.1.2.1 release, but I will merge the fix over to the 10.1 branch
for future releases.
andrew
Index: build.xml
===================================================================
--- build.xml (revision 330289)
+++ build.xml (revision 330290)
@@ -700,9 +700,13 @@
<property name="derby.jar.topdir" value="${basedir}/jars"/>
<mkdir dir="${derby.jar.dir}"/>
<mkdir dir="${derby.jar.dir}/lists"/>
- <loadfile srcFile="${basedir}/changenumber.properties"
+ <loadfile srcFile="${basedir}/changenumber.properties"
failonerror="false"
- property="changenumber"/>
+ property="changenumber">
+ <filterchain>
+ <striplinebreaks/>
+ </filterchain>
+ </loadfile>
<condition property="changenumber" value="???">
<not>
<isset property="changenumber"/>