Skip to content

5.1.1.Final release

Compare
Choose a tag to compare
@jadelkhoury jadelkhoury released this 29 Jun 19:33
· 221 commits to master since this release
3c0383b

[5.1.1.Final]

This content is a duplicate of the Change Log

Added

  • The OSLC Config domain model was expanded.
  • An OSLC4JUtils::isWellFormed method was added to help check the validity of strings as valid XML literals when the inputs are supposed to be used on properties of the rdf:XMLLiteral type. Warning: this method is quite slow, especially if a resource contains 10s or 100s of such values. We recommend to use this method only in tests.

Changed

  • Consistently save Credentials, Connector & admin_session values under session attribute, in the oauth-core AbstractAdapterCredentialsFilter class.
  • Apache Jena depency was updated from 4.5.0 to 4.8.0 due to CVE-2023-22665.
  • OSLC Domains are based on latest LyoDesigner, and for lyoVersion="5.0.1-SNAPSHOT".
  • The oslc4j-core artifact (group org.eclipse.lyo.oslc4j.core) was refactored, extracting some essential model classes into lyo-core-model and legacy Wink-dependent code into oslc4j-core-wink. This allows to eliminate all dependencies on Wink. Also, applications that don't need oslc4j-core, can eliminate the dependency on JAX-RS by replacing your dependency on oslc4j-core with lyo-core-model. No breaking changes were made.
  • JenaModelHelper was moved to oslc4j-core, while JsonHelper was moved to oslc4j-core-wink. No breaking changes were made, old package names were kept. See #292
  • OSLC4JConstants and OSLC4JUtils were extracted from oslc4j-core to org.eclipse.lyo.oslc4j.server:lyo-core-settings as they are only useful in the JAX-RS server-side scenarios. No breaking changes were made, because oslc4j-core still depends on the newly introduced artifact.

Deprecated

  • The newly refactored artifact oslc4j-core-wink is deprecated.

Removed

Fixed

  • A regression is fixed where org.eclipse.lyo.oslc4j.provider.jena.OslcRdfXmlProvider could try to unmarshal an Array or a Collection, which would interfere with the application of the suitable providers when the RDF input is correct.
  • PR 260 fixed the bug in ResourcePackages.getMostConcreteClassOf that could trigger the error "Multiple classes, not in the same inheritance tree, are annotated to map the same RDF:type".