DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22816>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22816 Continued multiple Class-Path: manifest attributes not parsed Summary: Continued multiple Class-Path: manifest attributes not parsed Product: Ant Version: 1.6Alpha (nightly) Platform: All OS/Version: All Status: NEW Severity: Major Priority: Other Component: Core tasks AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: [EMAIL PROTECTED] Overview Description: If a manifest file has multiple Class-Path: attributes and the second (or subsequent) are continued, then the continuted lines are not parsed correctly. Steps to Reproduce: 1) Use a MANIFEST.MF file like this Manifest-Version: 1.0 Created-By: 1.3.1 (IBM Corporation) Main-Class: com.ebay.kernel.batch.driver.BatchMain Class-Path: ../../../config/classes12.zip Class-Path: ../syslib/AFBusinessAPI.jar ../syslib/AFCommonAPI.jar ../s yslib/AFPresentationAPI.jar ../syslib/AFRT.jar [note: last line is continuation of line above it] 2) Use Ant to build a .jar using this manifest. For example, refer to the above file with ${manifest} in the task below <jar jarfile="${app.build.dir}/bin/BatchMain.jar" basedir="${global.build.temp.dir}/BatchMain" manifest="${manifest}"/> Actual Results: You would expect that the supplied manifest would be used. However, the continued second Class-Path: attribute is not correctly parsed. The generated .jar file has the following manifest file Manifest-Version: 1.0 Ant-Version: Apache Ant @VERSION@ Created-By: 1.3.1 (IBM Corporation) Main-Class: com.ebay.kernel.batch.driver.BatchMain Class-Path: ../../../config/classes12.zip Class-Path: ../syslib/AFBusinessAPI.jar ../syslib/AFCommonAPI.jar ../s Build Date & Platform: Ant 1.5.2 Additional Builds and Platforms: Verified that the bug still exists by code inspection of latest nightly build available, ant_20030829101220.tar.gz Additional Information: The bug occurs in the parsing of the manifest section, in the method Manifest.Section.read(BufferedReader reader) which begins around line 415 of Manifest.java. The main loop of the method uses a local variable, attribute, to hold the attribute parsed in the previous iteration. When a continuation line is detected, the continued value is added to this attribute. Attributes are added to the section under construction by calling the method addAttributeAndCheck. This method explicitly checks for additional Class-Path: Attribute objects. If any are found, the additional values are added to the Class-Path: Attribute already stored in the section rather than adding a whole new Attribute object to the section. The secondary Class-Path: Attribute object passed to addAttributeAndCheck is discarded and not added to the section. Unfortunately, the code that adds the continuation lines in the read () method is unaware of this, so it adds the continuation lines to the discarded object instead of the one stored in the attributes table of the section. One way to fix the problem would be to add two lines to the read() method as shown below to ensure that the local variable, attribute, always holds the right Class-Path: attribute public String read(BufferedReader reader) throws ManifestException, IOException { Attribute attribute = null; while (true) { String line = reader.readLine(); if (line == null || line.length() == 0) { return null; } if (line.charAt(0) == ' ') { // continuation line if (attribute == null) { if (name != null) { // a continuation on the first line is a // continuation of the name - concatenate this // line and the name name += line.substring(1); } else { throw new ManifestException("Can't start an " + "attribute with a continuation line " + line); } } else { attribute.addContinuation(line); } } else { attribute = new Attribute(line); String nameReadAhead = addAttributeAndCheck(attribute); if (nameReadAhead != null) { return nameReadAhead; } // In the rare case where a second Class-Path: attribute is // continued, we need to set the attribute loop variable // to the stored attribute, not the temporary one created // when the first line of the attribute value is read. if (attribute.getKey().equals(ATTRIBUTE_CLASSPATH)) { attribute = (Attribute) attributes.get(ATTRIBUTE_CLASSPATH); } } } } [The additional lines are the two that follow the comment, // In the rare case... at the end of the loop] I gave this a severity of Major, even though the use of multiple Class-Path: attributes is somewhat obscure because I need them and this bug is preventing me from using the <jar> task in a portion of our build. There doesn't seem to be a workaround available using this type of manifest file with Ant. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
