| Summary: | Need a home for Component tests | ||
|---|---|---|---|
| Product: | [Eclipse Project] Equinox | Reporter: | Jeff McAffer <jeffmcaffer> |
| Component: | Components | Assignee: | equinox.components-inbox <equinox.components-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | tjwatson |
| Version: | 3.5 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows Vista | ||
| Whiteboard: | stalebug | ||
| Bug Depends on: | |||
| Bug Blocks: | 261950 | ||
|
Description
Jeff McAffer
For compendium I created the org.eclipse.equinox.compendium.tests tests project. I had hoped all compendium tests could go in there. But we recently got a contribution from Stoyan for many new DS tests. The tests were rather extensive and complicated. In the end Stoyan preferred to keep these tests in a separate project org.eclipse.equinox.ds.tests. Since many of the service bundles in compendium are unrelated it may make sense to have separate test projects for them. Do we want to force all tests into a single project for components? Maybe its fine to start with one project but if we start getting more unrelated bundles in components will that continue to make sense to have one test project? If you eventually want to hook these tests into the build, then fewer bundles is better. For each test bundle there is mess of scripts to create/alter/maintain, so one test bundle per bundle would add a lot of unnecessary release engineering overhead. re comment 1: I was not intending to force all the tests in to one bundle but rather suggest that as a minimum the various areas should have easily identifiable tests in the Equinox repo. re comment 2: sigh BTW, I am all for having a small set of test bundles. I'm not sure it makes sense to have one test bundle per bundle, especially in the components, p2 or security areas. We can keep the ds tests separate and place the other compendium tests in one project if that helps releng. This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. Closing out stale bug. I think some of this has been addressed, but likely not all. |