Bugzilla – Full Text Bug Listing
| Summary: | [regression] inconsistent source folders management on the build path | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Fred Bricon <fbricon> | ||||||
| Component: | m2e | Assignee: | Fred Bricon <fbricon> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | critical | ||||||||
| Priority: | P3 | CC: | igor | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows 7 | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
|
Description
Fred Bricon
Looks very similar to bug 368333 actually. But in this case, src/main/resources is not generated. I should also add that I reproduced the problem using latest m2e-core sources from master, on Juno JavaEE M4 (and no m2e-wtp) The change to java source folders classpath entries is intentional, see bug 361549 for reasons behind this. Disappearing src/main/resources classpath entry is not expected and indeed the erroneous behaviour appears to be similar to bug 368333. Maybe we should just remove resources sources classpath entries... In AbstractJavaProjectConfigurator.addResourceDirs() (https://github.com/eclipse/m2e-core/blob/554e77b2d9fa56c3eaffa165f76d9020bdf4b25b/org.eclipse.m2e.jdt/src/org/eclipse/m2e/jdt/internal/AbstractJavaProjectConfigurator.java#L413) cped = getEnclosingEntryDescriptor(classpath, r.getFullPath()); returns a non-null value so it's not added to the classpath Created attachment 211731 [details]
Patch adding resource folders to classpath
Created attachment 211732 [details]
Test case verifying the resources are added after project update
I added the test to CustomClasspathTest.java then decided it could be renamed to JavaClasspathTest.java
Yes, both the fix and the test look reasonable. I pushed the test to github and also made you a committer on m2e-core-test (sorry it took so long). To make isResourceDescriptor 100% reliable, we can annotate resource IClasspathEntry with special attribute (for example, m2e.resource=true). It probably makes sense to check for entry kind too. But we can improve this later, if current implementation proves to be problematic. I also thought about tagging resource folders with some metadata. Not sure that'd make it 100% reliable though, as I believe new resources could be added by 3rd party plugins. (In reply to comment #8) > I also thought about tagging resource folders with some metadata. Not sure > that'd make it 100% reliable though, as I believe new resources could be added > by 3rd party plugins. Custom resources (any custom classpath entries, actually) are already handled differently and should be preserved. In fact, current implementation has a small bug, where custom source entries are replaced with m2e-managed during configuration update. Something added by this patch? (In reply to comment #10) > Something added by this patch? Yes. Steps to reproduce * manually create source folder "foo" with excludes=** (i.e. the same as auto-created resource classpath entry) * add "foo" resource in pom.xml , update project configuration * remove "foo" resource from pom.xml, update project configuration "foo" resource classpath entry was explicitly created by the user, so m2e is not expected to remove it, but I believe after this patch this is not longer the case. Very minor and very "edgy" scenario, so I would not worry about it until somebody complains. Indeed, the foo folder is removed, as m2e has no clue it was a custom resource folder originally. And that's a very very edgy case :-) (In reply to comment #12) > Indeed, the foo folder is removed, as m2e has no clue it was a custom resource > folder originally. And that's a very very edgy case :-) m2e DID know it was a custom resource originally but this information was wiped during project configuration update. Ok, if that's the case, then I'll look into it. (In reply to comment #14) > Ok, if that's the case, then I'll look into it. nah. nobody is going to notice ;-) |