Upgrade for powsybl-dependencies 2026.0.0#173
Conversation
Signed-off-by: Franck LECUYER <franck.lecuyer@rte-france.com>
|
Warning Rate limit exceeded
To keep reviews running without waiting, you can enable usage-based add-on for your organization. This allows additional reviews beyond the hourly cap. Account admins can enable it under billing. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. 📝 WalkthroughWalkthroughReplaces usages of IdentifiableType.DANGLING_LINE with IdentifiableType.BOUNDARY_LINE, removes helpers and logic that copied operational limits between lines, updates tests and test utilities to create boundary lines, and bumps two dependency version properties in Changes
Suggested reviewers
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (1 warning, 1 inconclusive)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…oltageLevel (now done in powsybl-core 7.2.0) Signed-off-by: Franck LECUYER <franck.lecuyer@rte-france.com>
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
src/test/java/org/gridsuite/modification/utils/NetworkUtil.java (1)
394-408:⚠️ Potential issue | 🔴 CriticalThe code has critical API compatibility issues with powsybl-core 7.2.0.
VoltageLevel.newBoundaryLine()does not exist in 7.2.0. Boundary lines are created at the Network level viaNetwork.newBoundaryLine().BoundaryLineAdder.setPairingKey()is not available in 7.2.0. The pairingKey method does not exist on BoundaryLineAdder.This method will fail to compile or run against powsybl-core 7.2.0.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/test/java/org/gridsuite/modification/utils/NetworkUtil.java` around lines 394 - 408, The createBoundaryLine method uses VoltageLevel.newBoundaryLine() and BoundaryLineAdder.setPairingKey(), which are not present in powsybl-core 7.2.0; update the implementation to create the BoundaryLine from the Network (use Network.newBoundaryLine()) instead of VoltageLevel.newBoundaryLine(), populate the same properties (id, name, r, x, b, g, p0, q0, node) on the Network boundary line adder, and remove or avoid calling setPairingKey() since BoundaryLineAdder.setPairingKey() is not available in 7.2.0 (if pairingKey must be recorded, set it via an alternative supported API after creation or store it externally). Ensure you reference and modify the createBoundaryLine method and replace VoltageLevel.newBoundaryLine() usages with Network.newBoundaryLine().
🧹 Nitpick comments (2)
src/main/java/org/gridsuite/modification/modifications/ByFilterDeletion.java (1)
53-53: Enum rename looks correct.One consideration outside this diff: if
ByFilterDeletionInfos.equipmentTypeis persisted as a string in upstream storage, existing records with"DANGLING_LINE"will fail to deserialize to the newIdentifiableType.BOUNDARY_LINE. A data migration or a deserialization alias may be needed in the owning service.🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/main/java/org/gridsuite/modification/modifications/ByFilterDeletion.java` at line 53, The enum constant IdentifiableType.BOUNDARY_LINE was introduced replacing DANGLING_LINE which may break deserialization of persisted strings; update the owning service to handle the old value by adding a Jackson alias or a data migration that maps persisted "DANGLING_LINE" to the new enum value, and ensure ByFilterDeletionInfos.equipmentType deserializes existing records (e.g., add `@JsonAlias` or a custom deserializer for IdentifiableType or run a one-time DB migration to replace "DANGLING_LINE" with "BOUNDARY_LINE").src/test/java/org/gridsuite/modification/utils/NetworkCreation.java (1)
112-114: Stale "dangling" naming in the adjacent switch IDs.The boundary-line equipment was renamed to
v2Boundary, but the cell switches (lines 113-114) are still namedv2bdangling/v2ddangling. These IDs are arbitrary for the test, but the outdated naming makes the network topology confusing to read. Since no other code references these identifiers, consider aligning them (e.g.,v2bboundary/v2dboundary) for consistency.🧹 Proposed rename
createBoundaryLine(v2, "v2Boundary", "v2Boundary", 10, 1, 2, 3, 4, 50, 30, "xnode1"); - createSwitch(v2, "v2bdangling", "v2bdangling", SwitchKind.BREAKER, true, false, false, 10, 11); - createSwitch(v2, "v2ddangling", "v2ddangling", SwitchKind.DISCONNECTOR, true, false, false, 11, 1); + createSwitch(v2, "v2bboundary", "v2bboundary", SwitchKind.BREAKER, true, false, false, 10, 11); + createSwitch(v2, "v2dboundary", "v2dboundary", SwitchKind.DISCONNECTOR, true, false, false, 11, 1);🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@src/test/java/org/gridsuite/modification/utils/NetworkCreation.java` around lines 112 - 114, Rename the two switches created adjacent to the boundary line so their IDs reflect the boundary name: change the createSwitch calls that currently use "v2bdangling" and "v2ddangling" to descriptive IDs like "v2bboundary" and "v2dboundary" respectively; update the string arguments in the createSwitch(...) invocations near createBoundaryLine(v2, "v2Boundary", ...) so both the ID and name parameters match the new names (references: createSwitch, v2bdangling, v2ddangling, v2Boundary).
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pom.xml`:
- Around line 45-46: The BOM import property powsybl-ws-dependencies.version set
to 2.32.0 is blocking CI because that artifact is not on Maven Central; revert
or change the property powsybl-ws-dependencies.version to the latest available
release (e.g. 2.31.0) in the pom (property name powsybl-ws-dependencies.version)
or wait for 2.32.0 to be published, then re-run CI; after updating, verify the
transitive powsybl-dependencies version (declared by the powsybl-ws-dependencies
BOM) so you know which powsybl-dependencies (e.g. powsybl-dependencies:2025.3.1)
will be pulled in.
---
Outside diff comments:
In `@src/test/java/org/gridsuite/modification/utils/NetworkUtil.java`:
- Around line 394-408: The createBoundaryLine method uses
VoltageLevel.newBoundaryLine() and BoundaryLineAdder.setPairingKey(), which are
not present in powsybl-core 7.2.0; update the implementation to create the
BoundaryLine from the Network (use Network.newBoundaryLine()) instead of
VoltageLevel.newBoundaryLine(), populate the same properties (id, name, r, x, b,
g, p0, q0, node) on the Network boundary line adder, and remove or avoid calling
setPairingKey() since BoundaryLineAdder.setPairingKey() is not available in
7.2.0 (if pairingKey must be recorded, set it via an alternative supported API
after creation or store it externally). Ensure you reference and modify the
createBoundaryLine method and replace VoltageLevel.newBoundaryLine() usages with
Network.newBoundaryLine().
---
Nitpick comments:
In
`@src/main/java/org/gridsuite/modification/modifications/ByFilterDeletion.java`:
- Line 53: The enum constant IdentifiableType.BOUNDARY_LINE was introduced
replacing DANGLING_LINE which may break deserialization of persisted strings;
update the owning service to handle the old value by adding a Jackson alias or a
data migration that maps persisted "DANGLING_LINE" to the new enum value, and
ensure ByFilterDeletionInfos.equipmentType deserializes existing records (e.g.,
add `@JsonAlias` or a custom deserializer for IdentifiableType or run a one-time
DB migration to replace "DANGLING_LINE" with "BOUNDARY_LINE").
In `@src/test/java/org/gridsuite/modification/utils/NetworkCreation.java`:
- Around line 112-114: Rename the two switches created adjacent to the boundary
line so their IDs reflect the boundary name: change the createSwitch calls that
currently use "v2bdangling" and "v2ddangling" to descriptive IDs like
"v2bboundary" and "v2dboundary" respectively; update the string arguments in the
createSwitch(...) invocations near createBoundaryLine(v2, "v2Boundary", ...) so
both the ID and name parameters match the new names (references: createSwitch,
v2bdangling, v2ddangling, v2Boundary).
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 7f6413e6-6918-43a6-b21a-51aba38743aa
📒 Files selected for processing (7)
pom.xmlsrc/main/java/org/gridsuite/modification/modifications/ByFilterDeletion.javasrc/main/java/org/gridsuite/modification/modifications/LineAttachToVoltageLevel.javasrc/main/java/org/gridsuite/modification/modifications/LineSplitWithVoltageLevel.javasrc/main/java/org/gridsuite/modification/utils/ModificationUtils.javasrc/test/java/org/gridsuite/modification/utils/NetworkCreation.javasrc/test/java/org/gridsuite/modification/utils/NetworkUtil.java
💤 Files with no reviewable changes (2)
- src/main/java/org/gridsuite/modification/modifications/LineAttachToVoltageLevel.java
- src/main/java/org/gridsuite/modification/modifications/LineSplitWithVoltageLevel.java
| <powsybl-ws-dependencies.version>2.32.0</powsybl-ws-dependencies.version> | ||
| <gridsuite-filter.version>1.22.0</gridsuite-filter.version> |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Confirm whether the referenced BOM version is published on Maven Central,
# and inspect which powsybl-dependencies version it imports if so.
set -e
BOM_URL="https://repo.maven.apache.org/maven2/com/powsybl/powsybl-ws-dependencies/2.32.0/powsybl-ws-dependencies-2.32.0.pom"
echo "Fetching $BOM_URL"
HTTP_CODE=$(curl -s -o /tmp/ws-deps.pom -w "%{http_code}" "$BOM_URL")
echo "HTTP status: $HTTP_CODE"
if [ "$HTTP_CODE" = "200" ]; then
echo "--- imports of powsybl-dependencies ---"
grep -A1 -B1 "powsybl-dependencies" /tmp/ws-deps.pom || true
fi
# Also list recently published versions
echo "--- maven-metadata.xml ---"
curl -s https://repo.maven.apache.org/maven2/com/powsybl/powsybl-ws-dependencies/maven-metadata.xml | tail -40Repository: gridsuite/network-modification
Length of output: 1470
🏁 Script executed:
#!/bin/bash
# Check the 2.31.0 BOM to see what powsybl-dependencies version it declares
BOM_URL="https://repo.maven.apache.org/maven2/com/powsybl/powsybl-ws-dependencies/2.31.0/powsybl-ws-dependencies-2.31.0.pom"
echo "Fetching 2.31.0 BOM to check powsybl-dependencies version..."
curl -s "$BOM_URL" | grep -A2 -B2 "powsybl-dependencies" | head -20Repository: gridsuite/network-modification
Length of output: 791
Pipeline build is blocked: powsybl-ws-dependencies:2.32.0 is not available on Maven Central.
The CI is failing with Non-resolvable import POM. Could not resolve com.powsybl:powsybl-ws-dependencies:pom:2.32.0, and every other reported POM error (missing versions on spring-web, powsybl-*, lombok, etc.) is a downstream effect of the BOM import failing — without the BOM, no managed versions are injected. Maven Central currently only hosts up to version 2.31.0 (released 2026-03-31). This PR cannot proceed until powsybl-ws-dependencies:2.32.0 is published.
When verifying after the release, note that 2.31.0 declares powsybl-dependencies:2025.3.1; confirm what version 2.32.0 will transitively require since it is not pinned directly in this PR.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@pom.xml` around lines 45 - 46, The BOM import property
powsybl-ws-dependencies.version set to 2.32.0 is blocking CI because that
artifact is not on Maven Central; revert or change the property
powsybl-ws-dependencies.version to the latest available release (e.g. 2.31.0) in
the pom (property name powsybl-ws-dependencies.version) or wait for 2.32.0 to be
published, then re-run CI; after updating, verify the transitive
powsybl-dependencies version (declared by the powsybl-ws-dependencies BOM) so
you know which powsybl-dependencies (e.g. powsybl-dependencies:2025.3.1) will be
pulled in.
Signed-off-by: Franck LECUYER <franck.lecuyer@rte-france.com>
…pendencies_2026.0.0 Signed-off-by: Franck LECUYER <franck.lecuyer@rte-france.com> # Conflicts: # src/test/resources/report/delete-attaching-line-report.txt # src/test/resources/report/delete-voltagelevel-on-line-report.txt
| <powsybl-ws-dependencies.version>2.31.0</powsybl-ws-dependencies.version> | ||
| <gridsuite-filter.version>1.21.0</gridsuite-filter.version> | ||
| <powsybl-ws-dependencies.version>2.32.0</powsybl-ws-dependencies.version> | ||
| <gridsuite-filter.version>1.22.0-SNAPSHOT</gridsuite-filter.version> |
There was a problem hiding this comment.
| <gridsuite-filter.version>1.22.0-SNAPSHOT</gridsuite-filter.version> | |
| <gridsuite-filter.version>1.22.0</gridsuite-filter.version> |
| protected void assertAfterNetworkModificationApplication() { | ||
| assertNull(getNetwork().getVoltageLevel("v1")); | ||
| assertNull(getNetwork().getSubstation("s1")); | ||
| assertNotNull(getNetwork().getVoltageLevel("v1")); |
| assertNull(getNetwork().getVoltageLevel("v2")); | ||
| assertEquals(3, getNetwork().getVoltageLevelCount()); | ||
| // v2 is still here | ||
| assertNotNull(getNetwork().getVoltageLevel("v2")); |
|
2 participants
PR Summary