Bugzilla – Full Text Bug Listing
| Summary: | ASF report generator can't locate test suites referenced from the workspace | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | amehrega |
| Component: | TPTP | Assignee: | Paul Slauenwhite <paulslau> |
| Status: | CLOSED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P2 | CC: | paulslau |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | closed471 | ||
| Bug Depends on: | 146678 | ||
| Bug Blocks: | |||
Also, once this defect is fixed the user shouldn't be forced to specify the property tptp.test.project. Currently not specifying this project name will result in exceptions. Will fix this in 4.4. I did further investigation and this limitation is also part of the test execution service. Specifically in the org.eclipse.hyades.test.core.services.AbstractTestExecutionService.execute() method. The "results" list containing the relative file path of testsuites assumes that the paths are relative to the project. Reassigning bug to different component and owner. Joe if you're not the right person could you reassign this bug. This was the designed behavior. Before I added the fileset functionality to the execution service, you still needed to specify both the workspace and the project, and the path to the suite was required to be project relative. The superclass of AbstractTestExecutionService has always been AbstractProjectSensitiveService, and all of its subclasses require that the project be specified. AbstractTestResultsPublicationService also extends AbstractProjectSensitiveService. I wouldn't mind working on this, though I think we'd need to put some thought into the design. I'd suggest it should be an enhancement, butu perhaps it's small enough to treat as a defect. We use the knowledge of both the workspace and the project when performing these services. In the case of test execution, we need to find the test suite(s) within their project in order to be able to execute them, and in the case of report publicaton, we need to find the test suite within its project so we can query to find the associated execution files. The fileset we pass in needs to be relative to something for us to be able to locate the specified files without recursively searching the entire workspace for each file. Since projects don't necessarily live within the workspace root directory (but still need to be open within the workspacve to be usable), it makes sense for the fileset to be relative to a given project. I guess the alternative you're suggesting would be for us to change the semantics of the services so that all filesets would be relative to the workspace rather than the project if the project parameter was not specified. I am somewhat concerned that this might further complicate the API, but perhaps it would be more intuitive than I am giving it credit for. I'm interested to hear what you guys think. My intentions were for the user to be able to freely set the value of the 'dir' attribute to any valid directory structure (a workspace, a project, or even a sub-directory belonging to a project). It would be nice if the service was smart enough to determine the path of the project using a combination of the path segments specified for the value of the 'dir' attribute and the value of the 'name' attribute for an included entity. So the short answer is we shouldn't limit the value of the 'dir' attribute to point to a workspace or a project but any directory structure that exists in the workspace (including the workspace itself). (In reply to comment #5) > So the short answer is we shouldn't limit the value of the 'dir' attribute to > point to a workspace or a project but any directory structure that exists in the > workspace (including the workspace itself). I don't think I agree with that approach for a couple of reasons. First, it would require searching potentially the entire workspace. Second, I'm not sure it could be made to work unambiguously, because projects can and sometimes do contain other projects within their directories. A good example of this is the TPTP test-results project which, in addition to being a simple project itself, contains lots of other projects as well. If both the test-results project and one of the projects that live within it were present in the workspace, we'd have no way to determine which element to choose (but it matters which one is chosen.) I can understand the desire to allow a fileset to span projects. What's the motivation for wanting to make the paths in a fileset relative to neither the workspace nor the project? It seems to me that you can do whatever wildcarding you'd want within the fileset anyway, and since all the services in question are workspace relative, I don't really see the usecase. With how things are currently designed, the user is forced to generate a separate report for each set of test suites belonging to a different project. Providing the ability to allow ‘dir’ to point to a workspace will allow the user to generate one report for all test suites contained in a workspace. If you don’t see any value of allowing ‘dir’ to point to an arbitrary directory, then I would like to see your proposed fix under comment #4. Thanks Joe. Targeting to future since not containable in 4.4. As discussed on this week's Test Project call (January 22, 2007), the Test Project will focus on existing P1 - P2/Blocker - Major and P1/Normal and test creation/automation defects (omitting defects dependant on outstanding features) in TPTP 4.4. All other Test Project defects have been targeted to future. If this defect has been targeted to future and you/originator feel it should be completed in 4.4, please provide the necessary reason as a reply to this comment or a post to the Test Project mailing list (tptp-test-tooling-dev@eclipse.org). We will collectively triage and assess our resources to determine a case-by-case decision. As discussed on this week's Test Project call (January 22, 2007), the Test Project will focus on existing P1 - P2/Blocker - Major and P1/Normal and test creation/automation defects (omitting defects dependant on outstanding features) in TPTP 4.4. All other Test Project defects have been targeted to future. If this defect has been targeted to future and you/originator feel it should be completed in 4.4, please provide the necessary reason as a reply to this comment or a post to the Test Project mailing list (tptp-test-tooling-dev@eclipse.org). We will collectively triage and assess our resources to determine a case-by-case decision. Correction: The Test Project mailing list is tptp-testing-tools-dev@eclipse.org. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. Since this defect is more than 2 years old, it may be no longer relevant. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this defect is resolved as WONTFIX. If this defect is still relevant and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open. |
When using ANT scripts to generate reports, the fileset defined as part of <tptp:publication element must have references from a project inside of a workspace. For exmaple, if a workspace is under "D:\Temp\test-pass" and a test suite is under plug-in/test-suites/JUnitTestSuite.testsuite, then the fileset must be: <fileset dir="D:\Temp\test-pass\plug-in"> <include name="test-suites/JUnitTestSuite.testsuite" /> </fileset> If the value of the 'dir' attribute points to a workspace, then the referenced test suite can't be resolved. For example, the following valid fileset will not work: <fileset dir="D:\Temp\test-pass"> <include name="plug-in/test-suites/JUnitTestSuite.testsuite" /> </fileset> The output of the ANT script is: adding file plug-in\test-suites\JUnitTestSuite.testsuite Can not find plug-in\test-suites\JUnitTestSuite.testsuite in workspace.