Summary: | Compiler failures in N20101101-2000 | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Olivier Thomann <Olivier_Thomann> | ||||
Component: | Runtime | Assignee: | platform-runtime-inbox <platform-runtime-inbox> | ||||
Status: | RESOLVED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | daniel_megert, kim.moir, tjwatson | ||||
Version: | 3.7 | ||||||
Target Milestone: | 3.7 M4 | ||||||
Hardware: | PC | ||||||
OS: | Windows 7 | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Olivier Thomann
2010-11-02 13:18:17 EDT
Created attachment 182222 [details]
Proposed fix
Olivier, this patch does not apply cleanly in my workspace unless I reverse the patch. So just to be clear, you are changing the following line in the build.properties to be: source.runtime_registry_compatibility.jar = src/, classes/ And removing the customBuildCallbacks line and file? Sorry DJ, I meant to report in this bug that I have released the patch to head. Waiting for test build to complete. Also note that I opened an API tooling bug329287 that shows up now if you checkout the code from head and have an API baseline of 3.6.x. Is there an explanation as to why this just started failing recently in the builds? (In reply to comment #5) > Is there an explanation as to why this just started failing recently in the > builds? I am trying to find out what has changed. So far, no luck. I updated to 3.7M3 bundles yesterday but we're not sure which bundle caused this issue to surface. btw, Tom your test build was succesful - no compile errors. (In reply to comment #8) > btw, Tom your test build was succesful - no compile errors. Thanks. I checked the build output from the test build and it is correct. I also left the patch released for last nights build and confirmed that the org.eclipse.core.runtime.compatibility.registry bundle got build correctly and has the correct content. I think the patch is a better way to build this bundle instead of the hack of using the classes/ folder as a source folder in the build.properties. Should not this bug be closed as FIXED? (In reply to comment #6) > (In reply to comment #5) > > Is there an explanation as to why this just started failing recently in the > > builds? > I am trying to find out what has changed. So far, no luck. Do we need a separate bug to track that? (In reply to comment #10) > Should not this bug be closed as FIXED? See above. (In reply to comment #11) > Do we need a separate bug to track that? yes. (In reply to comment #12) > (In reply to comment #11) > > Do we need a separate bug to track that? > yes. bug329853 opened. Closing this bug as fixed. The workaround has been released. I call it a workaround, but it is likely a better, and less hacky, way to build this anyway. |