Community
Participate
Working Groups
Currently, it's really hard for a contributor to understand that test there are automated tests in another repo to run. It's also a bad practice in general to separate tests from actual code, as "tests should be treated as 1-st class citizen". Having tests inside the m2e-core repo would allow to produce higher quality code faster.
m2e tests use hundreds (or thousands?) of thirdparty jars and sources provided by external contributors to the project. Unless there was a major change in Eclipse policies which I missed, all these sources and libraries will need to go through IP review process, with separate CQs filed for individual jars and source contributions. This is a lot of work, both to file the CQs and for the Eclipse IP team to review them, with virtually no benefit to the m2e users. On the other hand, location of m2e tests is clearly documented in http://www.eclipse.org/m2e/documentation/m2e-development-environment.html, which isn't perfect, but worked well enough so far and (the very few) contributors m2e gets usually have no problems providing tests there.
(In reply to Igor Fedorenko from comment #1) > m2e tests use hundreds (or thousands?) of thirdparty jars and sources > provided by external contributors to the project. Unless there was a major > change in Eclipse policies which I missed, all these sources and libraries > will need to go through IP review process, with separate CQs filed for > individual jars and source contributions. This is a lot of work, both to > file the CQs and for the Eclipse IP team to review them I've seen recently cases of CQ made of lots of different projects. Also the Type A IP check simplifies things. So I think there is some fresh hope. We should directly ask the IP team for this case. I can do it if you don't mind. > with virtually no benefit to the m2e users. Not directly, but there is a strong benefit for m2e contributors and reviewers by saving them time and effort, which would free them time and energy to work on m2e code itself and deliver value to end-users. There is a very strong correlation between how easy it is to contribute to a project, and how much value it can deliver to end-users. > On the other hand, location of m2e tests is clearly documented in > http://www.eclipse.org/m2e/documentation/m2e-development-environment.html, As Martin Fowler says in the "Refactoring" book, documentation is often a smell for the need of a refactoring ;) > (the very few) contributors It's IMO a chicken-egg problem: making project more "normal" brings more contributors and more contributors help the project being more "normal". So this kind of issue is IMO one factor that can help growing the amount of contributors (and the quality of their submission, thus reducing the "cost" of reviews). > contributors gets usually have no problems providing tests there. Just like for my recent patches, I didn't even run the tests nor would contribute to the repo. I would more for sure have done both if tests were co-located with code. Anyway, I'm pretty sure you agree with all these reasons to change move m2e tests (if possible). As we (Red Hat) want to make m2e better and sustainable -both technically and in term of "human resources"- for several stories, we'd be glad to get involved in issues like this one to make m2e simpler to contribute to. So this is not really a request for current m2e contributors to prepare or even perform the migration, it's more a proposal that I/we try to take care of it, and let current committers do whatever they have to do in the meantime, until a clear migration plan can be established and carried out. Would that be fine?
I do not believe having tests in a separate repository makes external contributes less likely, but I agree it'd be nice to have the tests and the main sources in the same place. I am glad RedHat is willing to invest into this non-trivial effort.
Opened CQ https://dev.eclipse.org/ipzilla/show_bug.cgi?id=18604
Alternative, you could use Git submodules which pull in the two repositories for the Jenkins job.
(In reply to Lars Vogel from comment #5) > Alternative, you could use Git submodules which pull in the two repositories > for the Jenkins job. That seed you threw here took some time to grow in me, and it's now implemented: The m2e-core repo contains a submodule reference to m2e-core-tests, which are populated with latest commit using `git submodule update --remote` and all that can run together in the same `mvn clean verify -Pits` command. CI jobs are configured to use it. I think this is already a good step in lowering the entry barrier of the project and motivating contributors to write tests.
Looks like we have a working solution.
Moved to https://github.com/eclipse-m2e/m2e-core/issues/
