Community
Participate
Working Groups
A typical maven project contains both its code for the project and the test code, each in a different source folder (see screenshot). At build time (maven build), each of these source folders are compiled using their own classpath (for example the test code would get JUnit). Now when such a project is imported in m2e, the problem is that both source folders get the same classpath, which means that a developer can start using classes from the test dependencies by accident. I'm opening this bug to to see how the behaviour of Maven could be mapped JDT facilities.
Jay, can you please follow up? Thanks!
This will be a big change. At this poing, I am not sure if we want to do this. Between, you can achieve this if you put them in two separate (dependent) projects if that's possible.
I think this is a general problem with "in-project" junit source-folder, not only maven-related. I am also looking for a solution to set up a source-folder specific classpath. This might be in form of "additional classpath" for (e.g.) the testsrc folder, where unit tests reside, or, the other way round, an exclusion filter per source-folder. (I prefer "addtional classpath", because in the typical "testsrc" scenario, you want to have just one source-folder with extended classpath) It would prevent developers from using code in production which is only intended for testing. We also thought about using separate projects, but the number of projects we have junit tests for is 41, so this would mean 41 additional projects, which each developer has to keep open. That is too much, a leaner solution is needed. Currently we quite often face the situation where testing code drips into production code, which is only noticed in CI quite a bit later. In most cases it is a sign of bad coding style/design, which could be noticed much earlier by a feature like this.
(In reply to Jayaprakash Arthanareeswaran from comment #2) > This will be a big change. Not just for the JDT itself, but also for all JDT/PDT clients too. I guess if one asks for that feature in JDT next request will be to extend it to PDT. Especially for PDT it can be hard: plugin projects can't have multiple MANIFEST.MF files per folder. What if the "maven" issue could be adressed by having kind of "access restrictions" on libraries per folder? E.g. junit.jar library can be used by "test" folder only? Would this mean less effort/changes for JDT? Still, this will not work for PDT. (In reply to Brindl Ronald from comment #3) > We also thought about using separate projects, but the number of projects we > have junit tests for is 41, so this would mean 41 additional projects, which > each developer has to keep open. That is too much, a leaner solution is > needed. We have ~70 product projects with ~70 test projects and nobody complains. > Currently we quite often face the situation where testing code drips into > production code, which is only noticed in CI quite a bit later. In most > cases it is a sign of bad coding style/design, which could be noticed much > earlier by a feature like this. Actually this can be easily done with already existing "feature" by moving production/test code to different projects.
Another reason to keep the tests in the same project is that many projects nowadays live at the very root of a Git repository. You definitely don't want a separate repository for your tests.
(In reply to Thomas Hallgren from comment #5) > You definitely don't > want a separate repository for your tests. Nobody tells you that you should separate them into different repos. You can have multiple projects in the same git/hg repository.
*** This bug has been marked as a duplicate of bug 105372 ***
