Summary: | Don't abort build when CompilationParticipants fix classpath | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Walter Harley <eclipse> | ||||
Component: | Core | Assignee: | Kent Johnson <kent_johnson> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | jerome_lanneluc, jgarms, kent_johnson, raj.alagumalai | ||||
Version: | 3.3 | ||||||
Target Milestone: | 3.3 M7 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Walter Harley
2006-12-01 01:39:19 EST
Created attachment 54867 [details]
suggested patch for 3.2.1
Here's the patch I've been testing on 3.2.1. It won't work on 3.3 because JavaProject methods have changed; my test scenario involves a lot of WTP plug-ins so I can't test on 3.3 yet, so I'm not sure how this should be done on 3.3.
Any chance of getting this in for M7? Jerome - updateClasspathMarkers() was removed. Is there another way we can force the classpath markers to be recomputed? I thought the resolution of this bug was make the APT generated source folder optional (see IClasspathAttribute#OPTIONAL) If the optional tag doesn't do the trick, let us know. The optional tag does indeed fix the problem for APT, thanks! Other compilation participants might not know how to fix this though. Two options I can think of to deal with this: 1) add a call to update the classpath in case a participant fixes it, or 2) document in the compilation participant API that they can use the optional tag on a classpath entry if they run into this case (a folder they create for generated files) APT is fine with #2, since that's what we're doing. It's also easier. ;) I'll update the spec to indicate that additional source folders should be tagged as optional. Updated the spec. Released for 3.3M7 Verified for 3.3M7 |