Community
Participate
Working Groups
Typically in my project I use two source folder : one for my source code, and one for my unit test source. I would like to have the possibility to not export my unit tests to the other projects, but I can't disable the checkbox in the project properties / Java build path / Order and Export. It seems that the source folder must always be exported.
A source folder is per definition a folder that is located on the build path. If you remove it from the build path, it is not a source folder anymore. I am not sure if we plan to change this in the future.
I don't want to remove it from the build path of my project! But I don't want to export the test classes to dependent projects.
*** Bug 41811 has been marked as a duplicate of this bug. ***
Source folders are indeed always exported, no plan to change this. The alternative would be to instead partitions your source folders in different projects. Closing.
*** Bug 199866 has been marked as a duplicate of this bug. ***
Given Eclipse's rules about pathname overlap, the resolution here is very problematic. It is a best practice to put unit tests into the same project as source. The alternative are a mare's nest of overlapping test and source projects, or detailed tweaking of the classpath in the run configurations of tests, or other hard-to-maintain issues. The export is often harmless, which is, I suppose, why this has been sitting quietly since 2003. I ran into it over the management of log2j configuration files. Is there any way to appeal this determination?
In Eclipse project, we usually put tests in a separate project that is dependent on the source project. This has worked very well for us. Can you please explain in more details why this doesn't work for you ?
Our style of development is to check the .project and .classpath into the source tree in source control, and import them directly into the project. Like a lot of other people, (especially people who use maven (which we don't)), we have a tree structure like logical top of project .classpath .project src test data build.xml test and src are the two directories of code. Some of the maven project I've seen have a far more complex structure. To be exact, I know that the src, data, test structure is very common. I'm really not clear on the relative popularity of checking in .project and .classpath and importing in-place versus 'checkout into project' patterns where the developers are forced to reconfigure their classpath and project settings whenever they set up a workspace. Our automated nightly builds use the build.xml, they don't run inside of eclipse. So we need a tree structure that works for both environments. The tests often touch the data at runtime. So it's very convenient for pathnames to look like 'data/xxx'. My belief is that Eclipse does not support resource pathnames that '..' out of the top of the project. So, let's say that we put a separate ./project/.classpath pair in the test and src directories. Now, we can't touch anything in the data directory (unless we create a linked resource) with an Eclipse path. We can touch it at runtime, of course, with .. pathnames. Our goal is to allow a developer to set up a workspace with an absolute minimum of Eclipse configuration. If we used Maven, I suppose that we could persuade the Maven Eclipse plugin to do all our work here, but we don't want to. So there you have it. On the one hand, I can't show you an absolutely impossible barrier to moving to your working model. On the other hand, all I/we are asking for here is to, I bet, remove a check from the code. I'd be willing to code a proposed patch if you were willing to accept the philosophical proposition that giving users this choice is no worse than the many other choices that they have.
I was just trying to understand your scenario. I have no philosophical problem with your setup. I'm just afraid it would break our code badly. Philippe, Kent, do you have more insights ?
I am excited at the fact that this request is being revisited. Our team has adopted the philosophy that unit tests are located in the same project as the primary source (like many open source projects). Functional/integration tests take myriad forms and are always located in a separate project. This ensures that developers can validate the code works regardless of environment. In addition we have dozens of projects. It doesn't seem practical to force 2x projects just to prevent inadvertent code dependencies on unit tests source, which is the primary objective of this request. I feel it is reasonable to have both your unit test source in the same project as your primary source and have assurance that no dependencies can be introduced onto unit test source and that unit test classes can never make it into production jar files. It seems some attention has been given to this issue since the order/export tab now prevents deselection of a source folder. Previously, the UI would allow you to deselect a source folder in order/export but Eclipse would not honor that deselection.
When you raise the possibility of breaking something, I want to present my vision of a 100%-compatible version of this idea. In concrete terms, the proposal here is to allow the 'exported' attribute to <classpathentry kind="src" path="src"/> element. By default, the value of this attribute would be 'true'. So, anyone who likes the current way of doing thing, could continue as before, no compatibility issue, no change.
I also do not have an issue with the setup, but... If the only issue is accidental references to test classes, then can you not make your test classes non-public (ie. default) visibility ? Wouldn't this accomplish the same thing and then Java is protecting you from referencing these types ? It would also prevent references from within the src folder of the project (something that export would not). Plus, there is no way we can support all setup cases: say, project A has 2 source folders: src & test and it has 1 output folder: bin the output folder is exported to dependent projects, not the individual source folders, so we cannot exclude the types from test, but export the types from src. We would need to validate the classpath to ensure that any source folder that is not exported has its own output folder & that no other source folder uses it. In the end, I'm not convinced we can address all users concerns without introducing some tricky bugs. Using non-public visibility for test classes seems more straight forward & definitely safer.
The original provocation was not test classes, but a log4j.properties file! Of course, I could replace it with programmatic logging config, but it seemed so natural to just click to stop exporting the test folder as a solution.
+1 for this. Standard maven/gradle structure include test artifacts in the same project as the main source code: /src/main/java /src/test/java /src/test/resources Since we can specify different output directories for each: target/classes target/test-classes it follows that we should have the ability to selectively export each output directory to dependent projects. The canonical use case is for having different logging configurations (logback-test.xml or log4j.properties) that you want local to each project. It's pretty disappointing that this hasn't been addressed in 12 years.
Things are probably going to change a bit (!) with the introduction of modules in Java 9. Let's see if that opens a new door for us.
+1 this issue is annoying as hell, in particular within CDI environments and testing. please, plase fix this.
(In reply to Jay Arthanareeswaran from comment #15) > Things are probably going to change a bit (!) with the introduction of > modules in Java 9. Let's see if that opens a new door for us. May be not. The current direction is that there will still be one source module per Java project. Bug 479483 has the discussion.
