Changelog and docs updated

Author: piconem

build.gradle.kts

@@ -23,12 +23,15 @@ mavenPublishing {
 dependencies {
     testImplementation("org.junit.jupiter:junit-jupiter-engine:5.10.1")
     //testImplementation("org.junit.jupiter:junit-jupiter:5.10.1")
-    testRuntimeOnly("org.junit.platform:junit-platform-launcher:1.10.1")
+    // Comment before publishing to avoid double signing of the same dependency
+    //testRuntimeOnly("org.junit.platform:junit-platform-launcher:1.10.1")
 }
 
 tasks.named<Test>("test") {
-    useJUnitPlatform()
-    //enabled = false
+    // Comment before publishing
+    //useJUnitPlatform()
+    // Uncomment before publishing
+    enabled = false
 }
 
 java {

docs/changelogs/v0.6.0.md

@@ -206,7 +206,6 @@ No breaking changes. Existing code continues to work unchanged. Applications can
 
 ### Physical Adapter Callbacks
 
-
 Physical Adapters can now receive and react to Digital Twin lifecycle events, enabling adaptive behavior based on synchronization state changes.
 While **Digital Adapters** have always received lifecycle updates to notify external observers and implement protocol-specific behavior, this capability was **missing on the Physical side** of the Digital Twin architecture.
 Physical Adapters can benefit from lifecycle awareness to:
@@ -241,9 +240,11 @@ Other `LifeCycleListener` callbacks are **not exposed** to Physical Adapters bec
 3. **Separation of Concerns**: Physical Adapters should be completely unaware of the Digital Twin's compute state, as managing or reacting to DT-level state is outside their responsibility domain
 
 Existing Physical Adapter implementations require **no changes**—the new callbacks have empty default implementations. Developers can opt-in by overriding `onDigitalTwinSync()` and/or `onDigitalTwinUnSync()` when lifecycle-aware behavior is needed.
+
 ### Missing adapter ID in PhysicalAssetWldtEvent
 
 This enhancement resolves **Issue #25** ([GitHub Link](https://github.com/wldt/wldt-core-java/issues/25)), which addresses a critical ambiguity problem in multi-adapter Digital Twin configurations.
+
 #### Problem Statement
 
 When multiple Physical Adapters publish variations to the physical world using identical keys (e.g., two adapters both reporting a `temperature` property), the **`DigitalTwinModel`** cannot distinguish the source adapter of each variation. This ambiguity prevents:
@@ -271,4 +272,15 @@ The `PhysicalAssetWldtEvent` class has been enhanced with a new `physicalAdapter
 
 1. Physical Adapters publish events using internal methods: `publishPhysicalAssetPropertyWldtEvent()`, `publishPhysicalAssetEventWldtEvent()`, `publishPhysicalAssetRelationshipCreatedWldtEvent()`, `publishPhysicalAssetRelationshipDeletedWldtEvent()`
 2. These methods automatically inject the adapter's ID via `setPhysicalAdapterId(String physicalAdapterId)` before event propagation
-3. The `DigitalTwinModel` and in generale physical events subscribers receive events with full source context
+3. The `DigitalTwinModel` and in generale physical events subscribers receive events with full source context
+
+### Refactoring for Content-Type in PhysicalAssetEvent
+
+Added `contentType` (String) field to the `PhysicalAssetEvent` class to allow adapters to communicate 
+the content type of the physical event body (e.g. `application/json`). 
+The field is fully accessible via getter and setter methods.
+
+With this change the `PhysicalAssetEvent` now includes the following fields:
+
+- `type`: Domain specific event type (e.g., "temperatureAlert", "motionDetected") that the developer can define based on the physical event semantics maybe with the support of a common ontology or taxonomy.
+- `contentType`: The content type of the event body (e.g., "application/json", "text/plain") that allows the receiving Digital Twin Model to correctly interpret the event payload.

docs/dt_definition_basic_concepts.md

@@ -156,7 +156,7 @@ As schematically illustrated in the previous Figure, involved steps are:
 2. Involved Physical Adapters communicate with the Physical Asset, receive data and generate Events (ePA)
    to notify about physical property changes
 3. Received ePA will be used by the Digital Twin Model in order to run the
-   Shadowing function and compute the new DT State
+   Shadowing process through its Digital Twin Model and compute the new DT State
 4. The DT can move from the Bound to Shadowed phase until it is able to maintain a proper synchronization
    with the physical asset over time through its shadowing process and the generation and maintenance of the DT's State
 
@@ -168,7 +168,7 @@ The Digital Twin State is structured and characterized by the following elements
 
 Listed elements can be directly associated to the corresponding element of the Physical Asset or generated by DT Model
 combining multiple physical properties, actions or relationships at the same time. The Digital Twin State can be managed
-through the Shadowing Function and exposes a set of methods for its manipulated. When there is a change in the DT State an event (eDT) will be generated
+through the Digital Twin Model and the implemented shadowing process and exposes a set of methods for its manipulated. When there is a change in the DT State an event (eDT) will be generated
 
 The manipulation of DT's State generates a set of DT's events (eDT) associated to each specific variation and evolution of the
 twin during its life cyle. These events are used by the Digital Interface and in particular by its Digital Adapters to