The OpenEdge Hive

Validation is disabled by default

To enable validation, create a directory "prolint/custom/rtb-check-in" and then copy file "prolint/roundtable/version/prolint-rtb-check-in.ini" to "prolint/custom/rtb-check-in/default.ini".


The ini file contains several tuning options for the validation.

The validation will read the options in file "prolint/custom/rtb-check-in/default.ini".

If a specific workspace requires specific validation options, you can also create a specific ini-file. For example: for workspace "MAINT" you can create a file named "prolint/custom/rtb-check-in/ws-MAINT.ini" (that is "ws-" + wspace-id + ".ini").

Fine-tuning the validation

Prolint runs every rule specified in profile "roundtable check-in". But not every warning from these rules should be an "error"; only errors will abort the Roundtable check-in procedure.
So you will have to define errors, and that is what file prolint-rtb-check-in.ini is for.

Includefiles versus CompilationUnits

When you want to check-in an includefile, Prolint will randomly select 3 compilation units (using the "where-used" XREF stored in Roundtable) and lint those instead. In this case, Prolint will only upgrade warnings to errors if those warnings are found in the includefile.
Other warnings from the selected compilation units will simply be skipped.

When you want to check-in a compilation unit, and Prolint discovers warnings in includefiles used by that compilation unit,
Prolint may or may not upgrade those warnings to errors based on settings in the following sections.
Warnings from the compilation unit will simply be upgraded to errors, unless the rule is not listed in section [error-rules].

section [error-rules]

[error-rules]
compiler=all
strattrib=all
substitute=module,my
noundo=module,my
varusage=module,my
ifindent1=module,my
dotcomment=module,my
noeffect=module,my

The first section, [error-rules] contains a list of rules. These are the rules whose warnings can be upgraded to errors. If profile "roundtable check-in" contains more rules they will run, but their warnings will just be warnings.

Prolint treats includefiles different from compilation units. After all, the programmer who is working on a compilation unit might not be responsible for the includefiles, and blocking errors from includefiles is counter-productive so you may want to tune that.


Each rule in the section can have attributes: "all", "module", "my" or any combination of these three. These attributes affect how warnings from includefiles are treated.

If attribute "all" is set, warnings from any includefile will be raised to errors.


"module" : warnings from an includefile will not be raised to errors, if the includefile is not located in the same module as the object you are about to check-in.


"my": warnings from an includefile will not be raised to errors, unless you "own" the includefile.


"module,my" : the includefile will cause an error if it is located in the current module OR if you "own" the includefile.

So when do you "own" an includefile? This is determined in the remaining sections.

section [behaviour]

[behaviour]
number-where-used=3
my-inc=programmer,manager,compltd-by

If Prolint finds a warning in an includefile, and "my" is specified in section [error-rules], then we have to decide if you "own" the includefile. Prolint assumes you "own" the file when you have ever worked on it.
Prolint reads the tasks list from Roundtable, and checks in each task if you were the manager, or the programmer, or if you were the person who completed the task.

key "my-inc" can have any combination of "programmer", "manager" or "compltd-by". This specifies which task fields are evaluated.

section [wildcards:not-my-includes]

[wildcards:not-my-includes]
src/adm/*.i=jurjen,john
src/adm2/*.i=*

Lost ownership? Suppose you were involved with an includefile in the past, but are not responsible anymore...


This section can contain a list of wildcard patterns for filenames. Each wildcard has a CAN-DO like list of user-names.
If the includefile matches any of these patterns, and you match the userlist, you are assumed to not "own" the includefile.
This overrides the outcome of key "my-inc" in section [behaviour]

section [wildcards:my-includes]

[wildcards:my-includes]
sports/*.i=john,bill

Same idea, but this time the other way around: If the includefile matches any of these patterns, and you match the userlist, you are assumed to "own" the includefile.
This overrides the outcome of section [wildcards:not-my-includes]