digital-pligtaflevering-aviser-tools

Clone Tools
  • last updated a few minutes ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Cleaned up IdValue, IdValueTest and ValidateXMLMain.

Individual XML validation result now placed on correct Doms item.

Cleaned ValidateXMLMain stream processing.

Ingester and VeraPDF tool now compiles with IdValue and ToolResultsReport.

SNAPSHOT: Reworking Mains to work with IdValue.

Added flatMap(v->..) and flatMap((id,v) -> ...) to IdValue.

SNAPSHOT: Revising ToolResult usage. Project does not compile.

Moved IdValue into dpa-api to be available everywhere.

Now named IdValue. of -> map and added create/filter

ContextValue -> StreamIdValue - plus test case.

Experimental ContextValue to test if key-value pairs make streams easier.

Let Netbeans remove unused imports.

Upgraded Maven compiler plugin to 3.7.0.

sbproject-parent module path was incorrect. Was not caught in original commit.

Merge remote-tracking branch 'origin/DPA-122' into DPA-122

VeraPDF file leak claimed fixed in version 1.9.50.

Copied in newspaper-parent-1.5 and sbutils-parent-18 to avoid dependency on sbforge nexus.

  1. … 125 more files in changeset.
DomsEvent was not used but raw fields. Refactored to fix.

  1. … 44 more files in changeset.
SNAPSHOT: Preparing to rewrite events storing to use DomsEvent.

SNAPSHOT: Rewrote ValidateXMLMain to Either and ToolResultsReport

SNAPSHOT: Replaced all usages of ToolCompletedResult with existing ToolResult class.

SNAPSHOT: Moved ToolResultTest with friends in the Doms module as ToolResult already lived here.

Merge remote-tracking branch 'origin/DPA-122' into DPA-122

SNAPSHOT: Beginning to rewrite Try to Either to work around Streams not being able to handle tuples.

dpa-verapdf: Humanly readable message changed slightly.

DPA-122: initial write-up on experiences on how to separate configuration from code when deploying.

    • -0
    • +112
    /CONFIGURATIONMAP-IN-DEPLOYMENT.md
DPA-122: verapdf autonomous component crashes if verapdf throws exception

Reenabled verapdf caching in DOMS to work around the file handling leak in VeraPDF.

Each invocation of VeraPDF saves the result in a VERAPDF data stream on the page.

After a crash the next run will use the cached output on the pages processed without

invoking VeraPDF so the next 4096 pages can be processed until eventually all have

been processed. This is a work around unfortunately :-/

Do not reuse verapdf streams to see how verapdf scales.

As verapdf still does not close its files after use,

an issue has been opened.

(https://github.com/veraPDF/veraPDF-apps/issues/218)