Repository navigation
Separate Jackson specific workflow from openworkflow-api module #1772
Description
Current openworkflow-api module contains method and utilities to read a workflow object into memory from a json/yaml and write a json/yaml file from its memory representation
The memory representation (Workflow.java) and the API method are jackson agnostic, but the implementation to load them depends on that library.
Following the same principle that was used in the reference implementation (to separate jackson dependeny moduled from agnostic ones) this module should be split into two, one with the interface and one with the jakcson stuff.
Taking benefit that moving to 8.0x (rebranding and jackson 3) breaks backward compatibility anyway, this is a good moment to do that change
A new module openworkflow-jackson-api will be defined (thats the one that will have to be included) and openworkflow-api become a base one for users that want to use a different json library.
This therotically allows (investing some effort to define required additional modules) to use a library different than jackson both for reading/writing and workflow execution
Activity
fjtirado commentedon Oct 20, 2026
After further reviewing openworkflow-api module, there are few things not jackson dependent.
In fact, only the values for JSON and YAML enum values (but not the logic enum), one static method to determine that value base on extension, and classpath reading are generic enough.
And that, in my opinion. does not justify the complexity of adding a separate module.
Maybe it would be good to rename the module from openworkflow-api to openworkflow-io-jackson, which reflect more accurately the functionality within it.
fjtirado commentedon Oct 20, 2026
After another thought, I think is better to not rename anything and document that, if someone wants to build a reader/writer not jackson based, they should use
openworkflow-typeas dependency of a new module that reads the file into those POJOS (which are jackson agnostic) in the most convenient way for their preferred json library.One can argue than a
Workflow read(InputStream input, WorkflowFormat format) throws IOException;method in a common interface is good enough, but maybe the json library do not use IOException (in fact jackson 3 does not longer use it, but we keep because we are using a jackson based validation library that still throws it ), maybe the library user does not fit well with java IO streams; maybe they want (as we are doing with jackson) add singleton features to WorkflowFormat enum. Yes, definetely I think is better to provide the generated pojos for those users that do not want to use jackson.[Fix open-workflow-specification#1772] Document jackson dependecy.