ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matt Lyon" <>
Subject RE: New Line in manifest
Date Fri, 14 Feb 2003 14:15:57 GMT
I'll try that out. Thanks for the suggestion. This would probably work a little bit better
for me than DD's suggestion, if only because I do want the ${version.major}.${version.minor}.${version.revision}.${}
values to be set as per what is defined in, and to be set with short default
string values otherwise in order to keep the Version: line in the jar's Manifest to one line
so that we don't get the breakage. 
I suppose another workaround would be to store the in CVS with default short
string values defined for the property values in question. It any case, it's certainly not
a huge issue to fix. I'm still not clear whether this should be considered any sort of Ant
issue or if it's really down to a char limit imposed on Manifest entries by the jar spec.

	-----Original Message----- 
	From: Mike Ayers [] 
	Sent: Thu 2/13/2003 5:29 PM 
	To: Ant Users List 
	Subject: RE: New Line in manifest

	> -----Original Message-----
	> From: Matt Lyon []
	> Sent: Thursday, February 13, 2003 2:14 PM
	> To: Ant Users List
	> Subject: RE: New Line in manifest
	> Thanks for the workaround idea... I'm trying to remember my
	> property inheritance rules... if I define them in the
	> buildfile with default values, the values that are set in
	> will still override, correct?
	        I, for one, am not sure, and hope you get an answer.
	        If you do not, you can always cascade...
	<condition property="version.M" value="${version.major}" >
	   <isset property="version.major" >
	<property name="version.M" value = "M" >
	        ...should provide you with the major version in version.M, or "M" if none is set.
 At least I think that's what it does - comments, anyone?  (Should I have used a condition
for the unset case?)
	To unsubscribe, e-mail:
	For additional commands, e-mail:

View raw message