Bugzilla – Full Text Bug Listing
| Summary: | Consider putting all test infrastructure in single repository | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | John Arthorne <john.arthorne> |
| Component: | PMC | Assignee: | Project Inbox <platform-pmc-inbox> |
| Status: | RESOLVED WONTFIX | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | daniel_megert, david_williams, dj.houghton, jamesblackburn+eclipse, kim.moir, Lars.Vogel, mober.at+eclipse, ob1.eclipse, sptaszkiewicz, Szymon.Brandys, tjwatson, tomasz.zarna |
| Version: | 4.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows 7 | ||
| Whiteboard: | |||
|
Description
John Arthorne
runtime repo would not be a bad choice, but ... as long as you are talking about "a separation that actually makes sense" and combined with the fact that "releng" repo is too large due to basebuilder, perhaps being in their own "relengTestAndTools" repo would be good. After all, I've heard, one advantage of Git is that "new repositories are easy" (though, I do not have enough first hand experience to know that for myself, yet). This caught my eye, because I know other projects (such as webtools) uses the test infrastructure (and cvs version of releng tool) so I'd think to other projects, it'd seem counter intuitive to have to load 'runtime' simply to get 'releng' things. (though, admittedly, few people I know load these things from any repo, and typically just install them in dev. env. or target). Just an idea. Regarding what makes sense, I think that testing is more a part of development than release engineering. I.e., all the committers who are working on changes to the code are typically writing and running tests at the same time. Most of these people will need the Java APIs in org.eclipse.test.performance and org.eclipse.core.test.harness to write and run those tests at development time. The release engineering part is the infrastructure for setting up headless tests, generating HTML result pages, etc. Developers rarely need to load that stuff because it is designed for use in automated builds. Most of this part of the test infrastructure is already in org.eclipse.releng.basebuilder. I do see two script files in org.eclipse.test.performance. I'm not sure if they are still in use (cs.sh, derby.sh), but maybe they belong in org.eclipse.releng.basebuilder along with all the other testing related scripts. Creating new repositories with Git is easy, but working with many Git repositories on a regular basis is a pain. For example if you want to catch up to "master" each day you need to do that on all of your repositories. For this reason we've tried to keep the number of repositories to a minimum (currently one per sub-project with a couple of exceptions). *** Bug 389737 has been marked as a duplicate of this bug. *** (In reply to comment #0) > I'm mainly entering this so I don't forget to bring it up for discussion. > > Several people so far have hit the problem that platform test infrastructure > is split across multiple git repositories. This means you need to clone > eclipse.platform.runtime and eclipse.platform.releng to get all the > prerequisites for running tests. This is not generally true, I never had to clone the runtime repo to run "my" performance tests. I would be OK with this change but only if I do not loose my commit rights on the performance framework by this move. I agree with Dani. The "right" way to use the test framework is to install it in dev environment or PDE runtime target. The plugins currently in the "test framework" is currently org.easymock_2.4.0.v20090202-0900.jar org.eclipse.ant.optional.junit_3.3.0.jar org.eclipse.test_3.3.100.jar org.eclipse.test.performance_3.8.0.v20120705-113326.jar org.eclipse.test.performance.win32_3.1.100.jar org.eclipse.test.source_3.3.100.jar org.hamcrest.core_1.1.0.v20090501071000.jar org.junit_4.10.0.v4_10_0_v20120426-0900.jar org.junit4_4.8.1.v20120705-112236.jar So ... if someone wanted ALL of those from "original source" repositories, they'd have a lot to load. Perhaps this is two issues: 1: Educating people on easiest way to use it. It is already a handy p2 repository that can be downloaded and installed, or installed from any Eclipse repo using the "org.eclipse.test" feature ... perhaps it needs a category there? Perhaps people don't realize its there?) And 2. eventually deciding how to structure repositories to make it easier to fit into maven/tycho builds ... from what I hear, it makes a difference? Perhaps I am missing why people want to load in to cvs workspace, but seems that should rarely be needed. (In reply to comment #5) > Perhaps I am missing why people want to load in to cvs workspace, but seems > that should rarely be needed. Until lately (3.7, maybe 3.6) the tests and test framework weren't available to be installed from a repo. So that's just what people are use to. Now we include them in our build repo, but we don't have a test harness feature (or test harness, ui test harness, performance test harness). They can still be installed with the director :-) PW (In reply to comment #6) > (In reply to comment #5) > > Perhaps I am missing why people want to load in to cvs workspace, but seems > > that should rarely be needed. > > Until lately (3.7, maybe 3.6) the tests and test framework weren't available > to be installed from a repo. So that's just what people are use to. > > Now we include them in our build repo, but we don't have a test harness > feature (or test harness, ui test harness, performance test harness). > > They can still be installed with the director :-) Or simply download the test framework once and then you're done. It doesn't change that often. I guess after 6 years we can assume nobody works on this. |