Skip to content

Release 0.8.0 (2026/04/26)

Latest

Choose a tag to compare

@eichelbe eichelbe released this 26 Apr 11:06
· 77 commits to main since this release

Release 0.8.0 focuses on consolidation, ReGaP basics, plugins and technical upgrades JDK 17/JDK 21/Angular19/Python 3.11. The artifacts are published to Maven Central, the platform handbook to Zenodo and the containers will be tagged on Dockerhub after they are re-built based on this tag. Versioned installation can be found here.

Improvements:

  • Support for JDK 21 based on Eclipse 2024-06.
  • Retrofit for BaSyx 1.5.1, in particular in AAS connector.
  • #106: Migration to JDK 17
  • Build process improvements for multiple Java/Maven installations like CI.
  • ReGaP: Influx/Grafana based dashboarding for oktoflow apps, integration of oktoflow2grafana.
  • #19: Integration of generated IDTA interfaces.
  • Revision of code generation to Java/Python/JSON/YAML artifacts provided by EASy-Producer
  • Code templates contain bash and batch scripts for building the app as well as a python source mapping for VScode
  • Reduced logging during execution of all-in-one examples
  • New INFLUX DB v3 connector for ReGaP.
  • #189: Revise documentation
  • #164: Management UI improvements
  • #170: Enable plugins/BaSyx2
  • #181: Allow MIMO containers
  • #166: Upgrade Angular for UI.
  • #171: Migrate build-jk.xml to maven deployment (where possible).
  • #173: Fix Python version selection for Python services.
  • #174: Moved examples.hm22 and examples.emo23 to own repository
  • #175: Revise Python tests, please check/adjust your Python tests according to the generated Python test templates.
  • #176: Archived/nailed-down basis containers for container generation.
  • #177: Local Python venvs in installation scripts.
  • #167: Generated Windows/Linux script line endings.
  • #178: Python console output.
  • #165: Upgrade automated container building/Python
  • #110: UI startup/excution complains (disappeared)
  • #160: Generated multi-type integration for KODEX
  • #186: Support displaying connector fields

New features:

  • #169: File-based connector for CSV, JSON (ReGaP)

Changes:
As part of cleaning up dependencies in the core components of oktoflow:

  • de.iip_ecosphere.platform.support.PythonUtils in support inherited from the Python Maven plugin became de.oktoflow.platform.tools.lib.PythonUtils in tools.lib, releasing dependencies
  • Turning Java objects generically into text is now done via de.iip_ecosphere.platform.support.StringUtils.toString(object) for a default format and de.iip_ecosphere.platform.support.StringUtils.toStringShortStyle(object) for the short format. The latter replaces the approach with org.apache.commons.lang3.builder.ReflectionToStringBuilder.toString(object, IipStringStyle.SHORT_STRING_STYLE) using de.iip_ecosphere.platform.services.environment.IipStringStyle as formatting. de.iip_ecosphere.platform.services.environment.IipStringStyle was internalized into de.iip_ecosphere.platform.support.StringUtils and, thus, can be/was removed from services.environment. Please re-build your applications.
  • The generated connectivity tests in src/test/java/iip/connectivity must be upgraded/taken over from the templates as connectors are not supposed to be instantiated directly anymore (plugin approach).
  • Check all application POM for direct use of oktoflow plugins. Plugins must not be stated as production dependencies while test dependencies are ok. Default plugins are added through the POM of the generated, integrated app.

Required adjustments:

  • Due to #181, inInterface and outInterface of connectors are now sequences, i.e., in IVML inInterface = {type=...} turns to inInterface = {{type=...}}, akin for outInterface, inAdapterClass and outAdapterClass.
  • Managed dependencies from oktoflow's parent POM are removed to keep (plugin) dependencies local and to prevent accidental classpath pollutions. Applications may have to change their POMs, e.g., slf4j dependencies are not needed anymore due to the integrated platform logging (please use inside) and some dependencies may need explicit versions (some are declared as properties in the platform's parent POMs). Only dependency-free platform core components shall use platformDependencies as parent POM, components/apps that need managed platform dependencies shall use platformDependenciesBOM (the bill-of-material) and components/apps that need the managed spring dependencies shall use platformDependenciesSpring.