Bugzilla – Full Text Bug Listing
| Summary: | Allow for different classpath on the source folder level | ||
|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Pascal Rapicault <pascal> |
| Component: | Core | Assignee: | Jay Arthanareeswaran <jarthana> |
| Status: | CLOSED DUPLICATE | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | amj87.iitr, eclipse, gunnar, loskutov, markus.kell.r, pierre-charles.david, robin, ronald.brindl, thomas, tomasz.zarna |
| Version: | 3.6 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Mac OS X - Carbon (unsup.) | ||
| See Also: | https://bugs.eclipse.org/bugs/show_bug.cgi?id=356450 | ||
| Whiteboard: | |||
|
Description
Pascal Rapicault
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 *** |