Bugzilla – Full Text Bug Listing
| Summary: | Missing builder results in an error log entry instead of a problem marker | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Konstantin Komissarchik <konstantin> |
| Component: | Resources | Assignee: | John Arthorne <john.arthorne> |
| Status: | VERIFIED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | IngedevTeam.fr, sengpl, Szymon.Brandys, thatnitind |
| Version: | 3.3 | ||
| Target Milestone: | 3.4 M4 | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
I also opened a related bug to track similar behavior as it applies to natures: https://bugs.eclipse.org/bugs/show_bug.cgi?id=178135 I like your suggested approach and this would be a good enhancement to explore for 3.4. *** Bug 187059 has been marked as a duplicate of this bug. *** I've been thinking about this behaviour, and decided it doesn't make sense to be logging anything here at all. It's quite common that a project configured with a builder from Web tools, CDT, JDT, or other project is loaded into an eclipse environment where such a builder is not present. This doesn't a "problem", but rather an everyday occurrence, and the message is cluttering the log (and confusing users) unnecessarily. This message is now only logged when the org.eclipse.core.resources/build/failure debug option is specified in the .options file. Verified in I20071210-1800. |
If a project refers to a builder id which is not found in the Eclipse install that the user is running, the platform logs a warning in the PDE error log that looks like this: "Skipping builder {x} for project {y}. Either the builder is missing from the install, or it belongs to a project nature that is missing or disabled." The problem that we are running into is that this behavior gets in a way of migration. BEA has been building on Eclipse for a while now and we have users whose projects need to migrated to BEA's new tooling. As part of the migration some builders are removed, others are renamed, etc. We run migration when we detect that a project has been imported. This works fine except for the fact that the user can later stumble on the above log entry (that no longer applies) and get confused. This case might be better handled by using a problem marker rather than writting to a log. This way when the problem is resolved (like it would after our migration had a chance to run), the problem marker would disappear and leave nothing for the user to get confused by. Also, using a problem marker would allow quick fixes to be registered (such as "Remove Builder" - maybe the user had used some tool that they have since discarded but the build spec still refers to it). If this approach makes sense, I would be willing to work on and contribute a patch for this. Let me know.