Bugzilla – Full Text Bug Listing
| Summary: | [ASF] The logical name of an execution history file is set incorrectly when the 'results' attribute is used | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | amehrega | ||||||||
| Component: | TPTP | Assignee: | Joe Toomey <jptoomey> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | |||||||||
| Severity: | major | ||||||||||
| Priority: | P1 | CC: | paulslau | ||||||||
| Version: | unspecified | Keywords: | plan | ||||||||
| Target Milestone: | --- | Flags: | paulslau:
review+
|
||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
This is not a regression, and appears to have been this way since 4.1. I can't see holding up 4.3 to try to make a change at this point. Targeting to 4.4 Joe, is there a workaround for this defect? If yes, can you post the workaround and decrease the severity to major (see http://www.eclipse.org/tptp/home/documents/process/development/bugzilla.html)? Joe, please review the priority. Has the priority for this defect been recently reviewed given its severity? If not, please take a few minutes and reevaluate the priority. Increasing the priority to P1 since including in the 4.4 plan. Increasing the priority to P1 since including in the 4.4 plan. sigh... Will need to do this in i2 The priority of this defect has not changed, but it is being deferred to i3 to allow for other work with UI changes that need to be complete in i2. Attaching patch. Created attachment 67045 [details]
Patch to properly handle results specifier
Created attachment 67046 [details]
mylar/context/zip
(In reply to comment #10) > Created an attachment (id=67045) [details] > Patch to properly handle results specifier > Can you confirm that resultsSpecifier is already trimmed? Also, should executionHistoryLocation have a default value in the even the folder odes not exist? Formatting the parameters is performed by the client adapters. For the ant adapter, this is done by ant itself, and for the command line adapter it's done by the OS (since the parameters are split based on spaces and put into the String argument array.) For the Java adapter, I guess this is a fair question, though the parameters are coming from Java itself, so the likelihood of trailing whitespace seems much lower. If you think this is an issue, I suggest we file a separate defect for this, since it applies to every parameter passed into every ASF service. executionHistoryLocation is initialized to null. It is read on (multi-)line 397, where we check to see if it's null, and only use its value if it is not. (In reply to comment #13) > Formatting the parameters is performed by the client adapters. For the ant > adapter, this is done by ant itself, and for the command line adapter it's done > by the OS (since the parameters are split based on spaces and put into the > String argument array.) > > For the Java adapter, I guess this is a fair question, though the parameters > are coming from Java itself, so the likelihood of trailing whitespace seems > much lower. If you think this is an issue, I suggest we file a separate defect > for this, since it applies to every parameter passed into every ASF service. I am always concerned when we use String#endsWith(String) and the target string in not trimmed. Is it possible for the user to specify a executionHistoryLocation with trailing whitespace? If so, can we trim the string in this method before the String#endsWith(String) calls? > executionHistoryLocation is initialized to null. It is read on (multi-)line > 397, where we check to see if it's null, and only use its value if it is not. Yes, I see that now:) Created attachment 68175 [details]
New patch that trims the resultSpecifier
Trim resultSpecifier
Patch reviewed. Please make a request to the Test Project mailing list for this defect. Once the fix is integrated, please add a comment to this defect containing the build ID of the driver used to verify the fix before marking the defect as fixed. Fix delivered. Will validate and close with next build. Adding hours worked Validated in TPTP-4.4.0-200705250100 |
When the 'results' attribute is used to specify a different location for the test execution file, the logical name of the execution file is set incorrectly. For example, if the results attribute is set to "junit_results/WINDOWS-IA32/JUnitTest", an execution history file, JUnitTest.execution, is generated under <project>/junit_results/WINDOWS-IA32 and the logical name of the execution file is set to junit_results/WINDOWS-IA32/JUnitTest as opposed to JUnitTest. Generating reports based on the execution file will fail. A tabular BIRT report will generate broken links. Fixing the logical name manually still generated one broken link. I'm marking this as critical because I wasn't able to come up with any workaround to generate a meaningful report. Here's the script that I'm using: <project name="Test Run" default="main" xmlns:tptp="antlib:org.eclipse.hyades.automation.client.adapters.ant"> <property name="tptp.automation.eclipse" value="D:/temp/test-driver/eclipse"/> <property name="tptp.test.workspace" value="D:/Temp/test-pass"/> <property name="tptp.automation.vmargs" value="-Xmx512m -DECLIPSE_STARTUP_PATH="D:/temp/TPTP-4.3.0-200610090100/eclipse/startup.jar" -DjavaHome="D:/Windows-Utilities/Java/Sun-1.4.2_10/bin/java.exe""/> <target name="main" depends="test-execution-0, test-interrogation-0"/> <target name="test-execution-0" description="Automatically Generated"> <tptp:test project="plug-in" suite="test-suites/JUnitTestSuite.testsuite" connection="tptp:rac://amehregani:10002/default" resultsrefid="tptp.test.results0" results="junit_results/WINDOWS-IA32/JUnitTestSuite"/> </target> <target name="test-interrogation-0" description="Automatically Generated"> <condition property="tptp.test.success"> <tptp:interrogation project="plug-in" verdictproperty="tptp.test.verdict"> <filelist refid="tptp.test.results0"/> </tptp:interrogation> </condition> <echo file="D:/temp/test-session/logs/TPTP-4.3.0-200610090100-1162924260093-status.txt" message="JUnitTestSuite.testsuite: ${tptp.test.verdict}
" append="true"/> </target> </project>