Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
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.

Initial try with Java 9. Appears Vaadin breaks :-/

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

  1. … 125 more files in changeset.
Work found on dla_mac

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
javaslang -> vavr project rename (which provides Try).

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 :-/