Community
Participate
Working Groups
Build Identifier: 201107091000 Dependent projects can access classes and resources from their dependencies as long as these are picked up from projects that are resolved by the m2eclipse feature to resolve dependencies from Workspace. Find an example multi module project below that shows the problem: https://github.com/codescape/sandbox/tree/master/m2eclipse-resolve-workspace Reproducible: Always Steps to Reproduce: 0. See https://github.com/codescape/sandbox/tree/master/m2eclipse-resolve-workspace 1. Import all three projects into Eclipse as Maven projects 2. See no compilation errors 3. Open "ConsumerTest" in consumer project 4. See the conflicting "extends ProviderTest" 5. Run "mvn test" on console or run "ConsumerTest" as a JUnit run inside eclipse to produce a java.lang.NoClassDefFoundError: de/stefanglase/ProviderTest
JDT treats each workspace project as single compile classpath entry. There is nothing m2e can do for finer-grained dependencies on projects until this is supported by JDT. Moving to JDT for consideration. Do note that runtime classpath is setup correctly already, so even though the test class in the provided example compiles, running the test using standard JDT "JUnit Test" launch configuration type fails with CNFE.
Igor, can you confirm that this is the same as bug 224708?
I believe this is a separate issue compared to bug 224708. This bug talks specifically about compile classpath dependencies among workspace projects and nothing else (see below for an example), while 224708 seems to concentrate on dealing with distinction between main and test sources, which is a problem already solved in m2e. For example, consider two typical Maven projects, A and B A/ src/main/java <- source folder src/test/java <- source folder target/classes <- output folder for src/main/java target/test-classes <- output folder for src/test/java B/ src/main/java <- source folder src/test/java <- source folder target/classes <- output folder for src/main/java target/test-classes <- output folder for src/test/java In Maven, dependency on project main and test outputs are treated separately, so A can depend on B's main output only or B's test output only or both main and test outputs. JDT, on the other hand, does not allow such fine-grained dependencies, and A can either depends on all B's outputs or none at all.
(In reply to comment #3) > ... 224708 seems to concentrate on > dealing with distinction between main and test sources, which is a problem > already solved in m2e. That's interesting. How does m2e solve it? > For example, consider two typical Maven projects, A and B ... Thanks, that explanation helps. How would the dependency be expressed? By explicitly mentioning the output folder to depend on, or by qualifying the project dependency with "test", or "main"?
(In reply to comment #4) > (In reply to comment #3) > > ... 224708 seems to concentrate on > > dealing with distinction between main and test sources, which is a problem > > already solved in m2e. > > That's interesting. How does m2e solve it? Maven project metadata has information about main and test source and output folders. There are few key usecases when m2e uses this information directly, like, for example, when launching tests, but otherwise it simply makes this info available to m2e extensions that integrate m2e with other tools. For example, m2e-wtp integration deals with filtering test-only dependencies from WebApp classpath (disclaimer: I have not looked at m2e-wtp code for very long time now, so my information may be couple of years out of date). > > For example, consider two typical Maven projects, A and B ... > > Thanks, that explanation helps. > How would the dependency be expressed? By explicitly mentioning the > output folder to depend on, or by qualifying the project dependency > with "test", or "main"? I am not sure what the implications are going one way or another. Maven model of what goes into main and test output folders is somewhat loose, it simply delegates to either maven itself or to thirdparty extensions and then picks the results in either main or test output folders. So for m2e it will be easier to express dependencies on output folders, assuming JDT will treat this as true in-workspace dependency.
(In reply to comment #5) > (In reply to comment #4) > > (In reply to comment #3) > > > ... 224708 seems to concentrate on > > > dealing with distinction between main and test sources, which is a problem > > > already solved in m2e. > > > > That's interesting. How does m2e solve it? > > Maven project metadata has information about main and test source and output > folders. There are few key usecases when m2e uses this information directly, > like, for example, when launching tests, but otherwise it simply makes this > info available to m2e extensions that integrate m2e with other tools. For > example, m2e-wtp integration deals with filtering test-only dependencies from > WebApp classpath (disclaimer: I have not looked at m2e-wtp code for very long > time now, so my information may be couple of years out of date). As you don't mention JDT here, doesn't this mean that in an m2e-configured Java project the incremental compiler will still compile with everything on one classpath and only when performing a full build via maven will errors about illegal access from regular classes to test classes be reported? Also content assist will propose test classes where it shouldn't, right? Or does m2e have a solution for that, too?
(In reply to comment #6) > (In reply to comment #5) > > (In reply to comment #4) > > > (In reply to comment #3) > > > > ... 224708 seems to concentrate on > > > > dealing with distinction between main and test sources, which is a problem > > > > already solved in m2e. > > > > > > That's interesting. How does m2e solve it? > > > > Maven project metadata has information about main and test source and output > > folders. There are few key usecases when m2e uses this information directly, > > like, for example, when launching tests, but otherwise it simply makes this > > info available to m2e extensions that integrate m2e with other tools. For > > example, m2e-wtp integration deals with filtering test-only dependencies from > > WebApp classpath (disclaimer: I have not looked at m2e-wtp code for very long > > time now, so my information may be couple of years out of date). > > As you don't mention JDT here, doesn't this mean that in an m2e-configured > Java project the incremental compiler will still compile with everything on > one classpath and only when performing a full build via maven will errors > about illegal access from regular classes to test classes be reported? > > Also content assist will propose test classes where it shouldn't, right? > Or does m2e have a solution for that, too? From the user experience I see that there is no solution in m2e for the content assist because I can see the test classes from regular classes. And that should not be the case.
> > As you don't mention JDT here, doesn't this mean that in an m2e-configured > Java project the incremental compiler will still compile with everything on > one classpath and only when performing a full build via maven will errors > about illegal access from regular classes to test classes be reported? > > Also content assist will propose test classes where it shouldn't, right? > Or does m2e have a solution for that, too? I knew I was forgetting something important! Yes, you are absolutely correct. Per-source-folder classpath is required to prevent "leaking" of test-only dependencies into main sources and there is not solution for this problem in m2e.
(In reply to comment #8) > I knew I was forgetting something important! Yes, you are absolutely correct. > Per-source-folder classpath is required to prevent "leaking" of test-only > dependencies into main sources and there is not solution for this problem in > m2e. OK, so that part is bug 224708 and it is unresolved also with m2e. Just wanted to be sure. What's new in this bug is the inter-project aspect.
Created attachment 238672 [details] demo project
Does anyone have a rough estimate of the difficulty and/or hours required to implement this? And will those in charge review and possibly accept patches for this bug? --- I think this one is rather insidious, since it silently corrupts the classpath of maven projects whenever a test scoped dependency is introduced. For simple projects this might even work because few will want to use JUnit and other testing frameworks in their non-test code. However, we have many maven projects where general-purpose libraries such as guava are allowed in unit tests, but must not be a compile time dependency due to conflicting library versions at deployment time (aka Maven dependency hell). Unsuspecting developers are using those libraries in non-test code because the classes show up in code assist, resulting in NoClassDefFoundErrors when the project is finally deployed :-/
(In reply to Daniel Huss from comment #11) I understand your situation and appreciate your interest. IIRC, the one-classpath-per-project rule was a deliberate design decision. Thus, before investing time in a patch we need agreement that s.t. like per-source-folder classpaths (or an alternative solution) are feasible and will be accepted by the JDT leads. Dani, can you say more? As to difficulty: it cuts deep into the innards of JDT and I'm not aware of a simple strategy to solve this. Some directions that I've been pondering about in the past: - indeed use two classpaths -> requires s.t. like working with two LookupEnvironments instead of one. No stone in the compiler would remain unturned. - multiple compiler invocations per project (isn't m2e already doing s.t. like this? sorry my memory fades ...) - use s.t. similar to access restrictions to mark test-only dependencies, but then we still need to know which source files are test vs. main (currently, the compiler doesn't care what source folder a source file comes from ...). Attaching some qualifier to dependencies found on some part of the class path and using matching qualifiers also for source files from different source folders might be the most promising direction. Still needs to be checked if type lookup always has the required context to know the qualifier of the source file. I'd be happy to participate in a discussion about possible directions, but only after Luna has sailed :)
What I need for m2e is ability to associate IJavaProject with any IContainer, not just IProjects, and have arbitrary many of these new IJavaProjects for each IProject. I actually prototyped this some time ago. Not a small or simple change by any means, but I think it is doable and will probably be pure extension to the existing API, i.e. won't break existing clients provided they are not exposed to this new type of IJavaProjects.
The Gradle plug-in will have a similar requirement of having a separate classpath for test and one for source. I have a build system that is still reliant on Ant and I would like to move to Gradle. My options are either to modify where Gradle looks for my test classes (I have to host these in different eclipse projects to get around this limitation), move to a different IDE (which is NOT my preference), or wait until this is fixed in Eclipse.
(In reply to Igor Fedorenko from comment #13) > What I need for m2e is ability to associate IJavaProject with any > IContainer, not just IProjects, and have arbitrary many of these new > IJavaProjects for each IProject. I actually prototyped this some time ago. > Not a small or simple change by any means, but I think it is doable and will > probably be pure extension to the existing API, i.e. won't break existing > clients provided they are not exposed to this new type of IJavaProjects. This goes into similar direction as bug 245412. If test and source could be expressed as nested projects, we would be able to define the dependencies. Such an approach might be more realistic than changing the design decision that each Java project lands on the classpath. As Stephan already pointed out, to change this we would have to touch a lot of places and it's definitely out of scope for the JDT team.
Bug 224708 provides a solution for separating main and test sources, including test-only dependencies. For further generalizations based on that, please open fresh, focused bugs. *** This bug has been marked as a duplicate of bug 224708 ***
