-
Notifications
You must be signed in to change notification settings - Fork 43
Migration guide v6.4.0
Starting from this release the Ref
interface and its implementations RefObj
and RefChain
are now in powsybl-commons artifact, in com.powsybl.commons.ref
package.
The Ref
interface was an internal utility class of powsybl-iidm-impl but its visibility was nonetheless public. If you were using this interface or one of its implementation, you need to replace the import clauses (e.g. the import com.powsybl.iidm.network.impl.util.RefObj;
with com.powsybl.commons.ref.RefObj;
), and include powsybl-commons
artifact in your pom.xml
file.
For SecurityAnalysisProvider
implementations, replace
run(Network, String workingStateId, LimitViolationDetector, LimitViolationFilter, ComputationManager, SecurityAnalysisParameters, ContingenciesProvider, List<SecurityAnalysisInterceptor>, List<OperatorStrategy>, List<Action>, List<StateMonitor>, List<LimitReduction>, ReportNode)
with
run(Network, String workingStateId, ContingenciesProvider, SecurityAnalysisRunParameters)
For SecurityAnalysis
API, the various run
and runAsync
methods overloads are now limited to:
run(Network, String workingStateId, ContingenciesProvider, SecurityAnalysisRunParameters)
runAsync(Network, List<Contingency>, SecurityAnalysisRunParameters)
runAsync(Network, List<Contingency>)
In this release, an effort was made to reduce the project's technical debt. This work introduced some breaking changes.
To avoid unsafe Jackson deserialization (see https://rules.sonarsource.com/java/RSPEC-4544/ ), classes implementing the interface BusRef
now have to add the Jackson annotation @JsonTypeName(".<ClassName>")
(with <ClassName>
replaced by the class name. Note the presence of the .
before the class name.).
For instance IdBasedBusRef
is annotated with @JsonTypeName(".IdBasedBusRef")
.
Following deprecated methods have been deleted:
Removed method | Replacement |
---|---|
PlatformConfig.setDefaultConfig |
Directly pass PlatformConfig instance to the code you want to test. |
PlatformConfig.moduleExists |
Test the result of PlatformConfig.getOptionalModuleConfig instead. |
PlatformConfig.getModuleConfig |
Use PlatformConfig.getOptionalModuleConfig instead. |
PlatformConfigNamedProvider.findBackwardsCompatible |
Use PlatformConfigNamedProvider.find instead. |
PlatformConfigNamedProvider.findDefaultBackwardsCompatible |
Use PlatformConfigNamedProvider.findDefault instead. |
StandbyAutomaton.getHighVoltageSetPoint |
Use StandbyAutomaton.getHighVoltageSetpoint instead. |
StandbyAutomaton.setHighVoltageSetPoint |
Use StandbyAutomaton.setHighVoltageSetpoint instead. |
StandbyAutomaton.getLowVoltageSetPoint |
Use StandbyAutomaton.setLowVoltageSetpoint instead. |
StandbyAutomaton.setLowVoltageSetPoint |
Use StandbyAutomaton.setLowVoltageSetpoint instead. |
StandbyAutomatonAdder.withHighVoltageSetPoint |
Use StandbyAutomatonAdder.withHighVoltageSetpoint instead. |
StandbyAutomatonAdder.withLowVoltageSetPoint |
Use StandbyAutomatonAdder.withLowVoltageSetpoint instead. |
UndirectedGraph.getMaxVertex |
If you override this method, rename it as getVertexCapacity() . |
PlatformConfigNamedProvider. ...BackwardsCompatible
methods' deprecation, "default"
keyword will not be supported anymore in configuration files. Thus check that you use "default-impl-name"
instead of "default"
in your configuration, especially in load-flow
and dynamic-simulation
sections.
The list returned by CandidateComputations.getComputationsNames()
is now immutable.
Following methods were renamed in ComparisonUtils
:
-
compareBytes
toassertBytesEquals
; -
compareTxt
toassertTxtEquals
; -
compareXml
toassertXmlEquals
.
This allows Sonar to detect these methods as assertions in the unit tests.
Custom IIDM implementation maintainers should define these new methods for Connectable
implementations:
-
boolean connect(Predicate<Switch> isTypeSwitchToOperate, ThreeSides side)
; boolean disconnect(Predicate<Switch> isSwitchOpenable, ThreeSides side)
They should act as their counterparts without the side
parameter, but only on the specified side.
This is not a breaking change, but we thought that this feature needed a special notice for IIDM implementation's maintainers.
When a new test class is added to the TCK ("The IIDM Technology Compatibility Kit"), its tests are not launched with your custom IIDM implementation unless you create a test class implementing it. But with the previous versions, nothing told you that new tests were added and you may though that your IIDM implementation was fully tested.
Starting from this release, a special TCK class was added to test that all other TCK tests are extended. To enable it, you need to create a new test class implementing AbstractTckSuiteExhaustivityTest
in your IIDM implementation's test directory:
class TckSuiteExhaustivityTest extends AbstractTckSuiteExhaustivityTest {}
This test will fail if any other TCK test is not extended in your own IIDM implementation's TCK test suite.
Custom IIDM implementation maintainers should add the following dependency in their TCK implementation's pom.xml
:
<dependency>
<groupId>org.assertj</groupId>
<artifactId>assertj-core</artifactId>
<scope>test</scope>
</dependency>