Bugzilla – Full Text Bug Listing
| Summary: | Add the ability to skip certain Eclipse builders or to mark their errors as non-critical | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | z_Archived | Reporter: | Christian Kesselheim <christian.kesselheim> | ||||||
| Component: | Buckminster | Assignee: | buckminster.core-inbox <buckminster.core-inbox> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | |||||||
| Severity: | enhancement | ||||||||
| Priority: | P3 | CC: | christian.kesselheim, thomas | ||||||
| Version: | unspecified | ||||||||
| Target Milestone: | --- | ||||||||
| Hardware: | Macintosh | ||||||||
| OS: | Mac OS X - Carbon (unsup.) | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
I'm currently running into a similar problem, just with the Xpand builder instead of the CheckStyle builder. I'm working on a patch to support skipping builders and ignoring errors of certain builders. For a first shot I'll simply use properties for the filtering. But I think this behaviour could really use a workspace preference setting. What do you think? (In reply to comment #1) > ... I think this behaviour could really use a > workspace preference setting. What do you think? I'm ambivalent about this. Workspace preferences are cumbersome because they need to be executed separately from the actual build. Properties are often simpler. They can be declared in a build.properties file that is provided to the actual build with a -P <file>. On the other hand, when running in the IDE, preferences is better because they will affect the incremental build. Then again, perhaps you really want to see the errors there. I agree, properties are much simpler. I was only thinking about preferences because this seemed to be a more "global" and permanent setting instead of something I'd typically change from action to action. Right now, I'm only working on filtering the builders in buckminster's AbstractBuildIntegrationActor, so the IDE's normal build (incremental or otherwise) wouldn't be affected anyway. Created attachment 182430 [details]
Adds property based filtering of builders and markers
This patch allows for flexible skipping of builders and/or ignoring certain build markers when deciding if the build was successful.
It adds three new properties:
- buckminster.builders.include - whitelist of builder ids to run
- buckminster.builders.exclude - blacklist of builder ids not to run (applied to whitelisted builders)
- buckminster.problems.ignore - marker types to ignore when determining build results
All property values are comma-separated regular expressions. This might actually be a bit over the top, though.
There's two points to this solution that I don't particularly like:
1) The buckminster.problems.ignore filters against marker ids, while the others filter against builder ids. I'd have preferred to use builder ids for the markers, too, both for uniformity and because marker ids are hard to deduce from the problems view. But there seems to be no generic way to map between builders and marker ids...
2) When excluding builders from the build process that have run earlier, their error markers won't be cleared away (and due to the builder<->marker mapping issue, I wouldn't know which ones to remove in the actor either). So it'd usually be necessary to exclude the markers, too, making excluding the builder a mere performance matter.
Created attachment 182431 [details]
mylyn/context/zip
Patch looks good. I committed it to helios-maintenance, rev 11621. Can you please provide some text that explains the properties that we can include in the documentation? Thanks. . Oh sorry, I've just now seen this coming from your newsgroup post. Apparently I forgot adding myself to CC :( I'll write something up this evening after work. Okay, here we go: ======== Properties controlling the build. By default, the eclipse.build actor will run a build using all builders configured in the Eclipse Build System. This behavior can be controlled through several properties: buckminster.builders.include Comma-separated list of regular expressions defining builders to run. All builders whose id matches at least one of the expressions are included in the build. If not specified, all available builders are used. buckminster.builders.exclude Comma-separated list of regular expressions defining builders to be excluded from the build. All builders whose id matches at least one of the expressions are ignored in the build. If both buckminster.builders.include and buckminster.builders.exclude are specified, only builders that match buckminster.builders.include but don't match buckminster.builders.exclude will be used. buckminster.problems.ignore Comma-separated list of regular expressions defining error marker ids to be ignored when determining build success. If the workspace already contains error markers for builders that are excluded the build, those markers will not be cleared by the build system and will cause the eclipse.build actor to fail. This property can be used to ignore these markers. Additionally it can be used to ignore build failures without disabling the corresponding builders. ======== I aimed for something similar to the property descriptions in site.p2 that can be added to the eclipse.build actor documentation. I'm not much of a documentation writer, so feel free to edit mercilessly... |
Build Identifier: I've recently run into a problem with my (Buckminster-driven) build that seems to have arisen at the time that I installed the standard Checkstyle Eclipse plug-in and enabled its use for all my OSGI/Eclipse RCP projects. Since then, its seems that any Buckminster build triggered from directly within the Eclipse IDE ("Buckminster > Run Action...") will fail if at least one of my plug-ins still has a error-level Checkstyle validation marker: =================== (Console) ====================== [start org.apache.oro:osgi.bundle$2.0.8.qualifier#eclipse.build] [end org.apache.oro:osgi.bundle$2.0.8.qualifier#eclipse.build] [start org.eclipse.riena.client:osgi.bundle$2.1.0.qualifier#eclipse .build] [end org.eclipse.riena.client:osgi.bundle$2.1.0.qualifier#eclipse .build] [start lu.kreios.mtg.client:osgi.bundle$1.0.0.qualifier#eclipse.bui ld] '4' is a magic number. <- Actually a Checkstyle violation message ==================================================== ===================== (Log) ======================== !ENTRY org.eclipse.buckminster.core 4 293 2010-07-02 16:55:22.717 !MESSAGE '4' is a magic number. ==================================================== When this happens, Buckminster seems to display the supposed "error message" (coming from Checkstyle) within both the standard console as well as within a dedicated message box and simply abort the build. While this may be just the desired behavior for errors occurring within some of the more "critical" builders of one's own project (e.g. the Scala builder for Scala-based projects), it's certainly sub-optimal for builders that play only a "supporting" role within the overall process (e.g. collect some metrics). Thus, it'd be great if Buckminster could somehow (e.g. by means of a property) either instrument PDE Build to skip certain Eclipse builders or at least continue to run the remaining parts of the build process if one of these builders comes back with an error. Reproducible: Always Steps to Reproduce: 1. Install CheckStyle Eclipse plug-in (eclipse-cs) and enable its use for an arbitrary plug-in project 2. Hack-in some code that makes CheckStyle issue at least one violation of type error 3. Attempt to build the plug-in via Buckminster