We need a better management of the (Extraction/Import)-Pipeline for a Bconf. It should be possible, to validate a Pipeline step by step and make sure, that the 3 mandatory steps (RawDocumentToFilterEventsStep, SegmentationStep, ExtractionStep) are present. Additional Steps should be allowed. The SegmentationStep and ExtractionStep should be additionally compared against a seperate Step-Properties-File (application/modules/editor/Plugins/Okapi/data/pipeline/step/translate5) that defines properties that must be set in the given way. These definitions are simply set or added if not present in the given way without error or feedback.

These validations should be done when importing a BCONF and uploading a pipeline. The mandatory Properties should also be set/updated if neccessary on a BCONF upgrade, due to an inceased version index (repackIfOutdated) or a general upgrade-script for the framework-version.

This should be implemented in a way (class naming), that we have the option to validate & update/upgrade export/merging pipelines as well if this becomes neccessary

• Classes for Steps in /Okapi/Bconf/Step/
• Step-Classnames equal step in Pipeline: net.sf.okapi.steps.rainbowkit.creation.ExtractionStep => ExtractionStep
• Validation per step: All steps valid -> Pipeline valid
• Integrate Pipeline into general "versioned upgrade" mechanism like SRX and FPRM
• [Perspectively: Frontend shall make steps editable & addable]

The whole version-mechanic should be part of the Pipeline Code and needs to be improved

• in Pipeline::parse, add the BCONF-Version if not present or update it, if not current
• The saving in Pipeline::parse saves twice (as Pipeline::flush() is called anyway in the BconfUnpacker on import). It is even dangeraous in case one wants only to analyse a Pipeline, data should never be written in a parse-function. Please remove
• Add a Pipeline::flush to the Packer only, if the version is not the current. Do it with the Pipeline-Entity via an explicit API if needed