Set the root report bundle resource to get the powsybl-core resource … #1207
Conversation
alicecaron
force-pushed
the
set-root-report-bundle
branch
from
7298ca3 to
38498ad
Compare
…bundle Signed-off-by: CARON Alice <[email protected]>
alicecaron
force-pushed
the
set-root-report-bundle
branch
from
38498ad to
657c293
Compare
Yes! I corrected to precise the powsyl core bundle name to keep it light |
Signed-off-by: CARON Alice <[email protected]>
alicecaron
force-pushed
the
set-root-report-bundle
branch
from
eaf1267 to
03956a9
Compare
|
alicecaron
changed the title
| @@ -623,6 +624,7 @@ public static ReportNode createLoadFlowReporter(ReportNode reportNode, String ne | |||
|
|
|||
| public static ReportNode createRootLfNetworkReportNode(int networkNumCc, int networkNumSc) { | |||
| return ReportNode.newRootReportNode() | |||
| .withResourceBundles(PowsyblCoreReportResourceBundle.BASE_NAME) | |||
| .withMessageTemplate(LF_NETWORK_KEY, "Network CC${networkNumCc} SC${networkNumSc}") | |||
There was a problem hiding this comment.
@jeandemanged how does this work for you ?
The bottom line is that:
- All messages moving forward, should be in a resource bundle (to enable multi-language support)
- If open load flow creates a root report node, all messages added to the report node should be in the root bundle list
- This includes:
- calls made to core (covered by this PR)
- messages added by OLF (not covered by this PR)
- calls made to OLF extensions
As of today, there is an alternative API currently to add all bundles in the class path to the report.
We create root reports today in mutlithreaded secu analysis, and in some other occasions, ofr example where we want to control the addition of a node depending whether it has children or note.
-
DO NOT MERGE. THIS PR IS SUPERSEDED BY #1216
(PR done perpared in case severe issue occure in 1.15.0)
Please check if the PR fulfills these requirements
What kind of change does this PR introduce?
Follow migration guide for core version 6.7.0-RC1 on ReportNode to load powsybl-core bundle for message templates.
Does this PR introduce a breaking change or deprecate an API?