[JBoss JIRA] (DROOLS-2254) Automate .proto files rebuild in pom.xml
by Michael Biarnes Kiefer (Jira)
[ https://issues.jboss.org/browse/DROOLS-2254?page=com.atlassian.jira.plugi... ]
Michael Biarnes Kiefer updated DROOLS-2254:
-------------------------------------------
Fix Version/s: 7.29.0.Final
(was: 7.28.0.Final)
> Automate .proto files rebuild in pom.xml
> ----------------------------------------
>
> Key: DROOLS-2254
> URL: https://issues.jboss.org/browse/DROOLS-2254
> Project: Drools
> Issue Type: Task
> Components: tools
> Affects Versions: 7.5.0.Final
> Reporter: Dmitry Volodin
> Assignee: Dmitry Volodin
> Priority: Minor
> Fix For: 7.29.0.Final
>
>
> According to contribution guide, any .proto file or protobuf version changes it's necessary to download protoc utility and regenerate Java classes based on .proto files.
> This will add automation for downloading protoc utility and Java classes generation based on Maven Protocol Buffers Plugin. There is no timestamps and other build related info inside generated Java files and no changes will be added on each new build.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4551) Build fails when condition in spreadsheet contains '(' and ')' separately as a value
by Luca Molteni (Jira)
[ https://issues.jboss.org/browse/DROOLS-4551?page=com.atlassian.jira.plugi... ]
Luca Molteni resolved DROOLS-4551.
----------------------------------
Release Notes Text: See https://issues.jboss.org/browse/RHDM-1095 comments
Resolution: Won't Fix
> Build fails when condition in spreadsheet contains '(' and ')' separately as a value
> ------------------------------------------------------------------------------------
>
> Key: DROOLS-4551
> URL: https://issues.jboss.org/browse/DROOLS-4551
> Project: Drools
> Issue Type: Bug
> Components: build, decision tables
> Affects Versions: 7.25.0.Final, 7.26.0.Final
> Environment: - 7.25.0.Final or 7.26.0.Final
> - spreadsheet decition table
> - EscapeQuote: false
> Reporter: Hiroko Miura
> Assignee: Luca Molteni
> Priority: Major
> Labels: support
> Attachments: dt-build-err.zip
>
>
> If condition contains '(' and ')' separately as different value in value cell, build fails with error like:
> {noformat}
> [main] ERROR Unable to build KieBaseModel:dtables
> Unable to Analyse Expression $2:
> [Error: unable to resolve method using strict-mode: com.sample.Message.$2()]
> [Near : {... $2 ....}]
> ^
> [Line: 6, Column: 2] : [Rule name='HelloWorld_11']
> {noformat}
> This worked with 7.18.0.Final-redhat-00004 (RHDM7.4.1), but fails with 7.25.0.Final or 7.26.0.Final.
> Condition in DRL generated by spreadsheet compiler are different per these version.
> - 7.25.0.Final/7.26.0.Final
> {noformat}
> m:Message(status in (Message.HELLO), errorMessage in ("Hello", "Hi"), $2)
> {noformat}
> - 7.24.0.Final/7.18.0.Final
> {noformat}
> m:Message(status in (Message.HELLO), errorMessage in ("Hello", "Hi"))
> {noformat}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12663) Upgrade jgroups-kubernetes to 1.0.13.Final
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-12663?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-12663:
----------------------------------
Description:
Solves:
* KUBE_PING warning with StatefulSet
* KUBE_PING too frequent warning metadata.labels.pod-template-hash not found in pod json. Impossible to reliably determine pod group during Rolling Update
* Initial discovery ends up in singleton partitions
was:
Solves:
* * KUBE_PING warning with StatefulSet
* KUBE_PING too frequent warning metadata.labels.pod-template-hash not found in pod json. Impossible to reliably determine pod group during Rolling Update
* Initial discovery ends up in singleton partitions
> Upgrade jgroups-kubernetes to 1.0.13.Final
> ------------------------------------------
>
> Key: WFLY-12663
> URL: https://issues.jboss.org/browse/WFLY-12663
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Clustering
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
>
> Solves:
> * KUBE_PING warning with StatefulSet
> * KUBE_PING too frequent warning metadata.labels.pod-template-hash not found in pod json. Impossible to reliably determine pod group during Rolling Update
> * Initial discovery ends up in singleton partitions
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (WFLY-12663) Upgrade jgroups-kubernetes to 1.0.13.Final
by Radoslav Husar (Jira)
[ https://issues.jboss.org/browse/WFLY-12663?page=com.atlassian.jira.plugin... ]
Radoslav Husar updated WFLY-12663:
----------------------------------
Description:
Solves:
* * KUBE_PING warning with StatefulSet
* KUBE_PING too frequent warning metadata.labels.pod-template-hash not found in pod json. Impossible to reliably determine pod group during Rolling Update
* Initial discovery ends up in singleton partitions
> Upgrade jgroups-kubernetes to 1.0.13.Final
> ------------------------------------------
>
> Key: WFLY-12663
> URL: https://issues.jboss.org/browse/WFLY-12663
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Clustering
> Reporter: Radoslav Husar
> Assignee: Radoslav Husar
> Priority: Critical
>
> Solves:
> * * KUBE_PING warning with StatefulSet
> * KUBE_PING too frequent warning metadata.labels.pod-template-hash not found in pod json. Impossible to reliably determine pod group during Rolling Update
> * Initial discovery ends up in singleton partitions
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months
[JBoss JIRA] (DROOLS-4640) DMN Editor constraint on Type does not reflect in Decision Table
by Michael Anstis (Jira)
[ https://issues.jboss.org/browse/DROOLS-4640?page=com.atlassian.jira.plugi... ]
Michael Anstis commented on DROOLS-4640:
----------------------------------------
[~tari_manga] Could you please clarify your expectation?
The {{ItemDefinition}} "Violation.Type" presumably has a constraint defined as an enumeration for "speed", "parking" and "driving under the influence".
I assume you expect the {{InputClause.UnaryTests}} to auto-magically also be defined as the same enumeration?
Furthermore, presumably, if the constraint for "Violation.Type" is changed the {{InputClause.UnaryTests}} should change too? Does this relationship work both ways? i.e. should the User be able to modify the {{InputClause.UnaryTests}} and this be reflected in the "Violation.Type" constraint, or should the {{InputClause.UnaryTests}} be read-only and always reflect the {{ItemDefinition}} constraint?
Do you know of other scenarios when the same behaviour should apply? e.g. {{OutputClause.UnaryTests}}. Any others?
> DMN Editor constraint on Type does not reflect in Decision Table
> ----------------------------------------------------------------
>
> Key: DROOLS-4640
> URL: https://issues.jboss.org/browse/DROOLS-4640
> Project: Drools
> Issue Type: Enhancement
> Components: DMN Editor
> Reporter: Matteo Mortari
> Assignee: Guilherme Gomes
> Priority: Major
> Attachments: image-2019-10-11-11-02-31-881.png
>
>
> Editing the classic Traffic Violation item definition to put enumeration on string for the violation type "speed", "parking", ... once done in the item definition is not reflected in the decision table, and that prevents also from getting the real intended DT static analysis message for the table.
> !image-2019-10-11-11-02-31-881.png|thumbnail!
> in the attached screenshot I entered the data also manually in the DT's property right tab.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years, 9 months