[JBoss JIRA] (DROOLS-2706) New "Scenario Test" asset list option (UX)
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2706?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2706:
-------------------------------------
[~ibek] Could we go with "Rule Scenario Test (Preview)" as [~stetson.robinson] had previously suggested and cross the other asset type bridge when we come to it?
> New "Scenario Test" asset list option (UX)
> ------------------------------------------
>
> Key: DROOLS-2706
> URL: https://issues.jboss.org/browse/DROOLS-2706
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
>
> As a practitioner - I want to be able to distinguish the new Scenario Test tool option, from the existing one, within the Asset list so that I can quickly/easily create a test using the new editor.
> *Verification conditions:*
> The new Scenario Test tool is distinguishable from the existing test tool within the asset list, through visual inspection by the user (no hover/click required.)
> Notes:
> Need a way to identify "experimental" tools from existing (to be deprecated?) tools. Solution might include distinct names for each, or parenthetical append (e.g. "experimental, beta, preview...) Or visual indicator, such as an icon, flag, etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10520) Add Hibernate ORM 5.3 compatibility transformer
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10520?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-10520:
-------------------------------------
[~gbadner] I agree, the WF documentation should mention how the transformer can be enabled.
> Add Hibernate ORM 5.3 compatibility transformer
> -----------------------------------------------
>
> Key: WFLY-10520
> URL: https://issues.jboss.org/browse/WFLY-10520
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Scott Marlow
> Fix For: 14.0.0.CR1
>
>
> A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1.
> From https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-w...
> # Change call to org.hibernate.BasicQueryContract.getFlushMode() to instead call BasicQueryContract.getHibernateFlushMode().
> # Change call to org.hibernate.Session.getFlushMode, to instead call Session.getHibernateFlushMode()
> # App References to Enum org.hibernate.FlushMode.NEVER (0) should be transformed to reference FlushMode.MANUAL (0) instead.
> # For call to org.hibernate.Query.getMaxResults() returning Integer, instead call org.hibernate.Query.getHibernateMaxResults() (returning Integer).
> # For call to org.hibernate.Query.setMaxResults(int), instead call org.hibernate.Query.setHibernateMaxResults(int).
> # For call to org.hibernate.Query.getFirstResult(int) returning Integer, instead call org.hibernate.Query.getHibernateFirstResult() (returning Integer).
> # For call to org.hibernate.Query.setFirstResult(int), instead call org.hibernate.Query.setHibernateFirstResult(int).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2706) New "Scenario Test" asset list option (UX)
by Liz Clayton (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2706?page=com.atlassian.jira.plugi... ]
Liz Clayton commented on DROOLS-2706:
-------------------------------------
[~stetson.robinson] I agree the word "Test" offers clarity. I'm working on the Add dialog and Add "Scenario Simulation" doesn't sound right - simulating a scenario for what? Plus I believe a single test would typically contain multiple scenarios.
> New "Scenario Test" asset list option (UX)
> ------------------------------------------
>
> Key: DROOLS-2706
> URL: https://issues.jboss.org/browse/DROOLS-2706
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
>
> As a practitioner - I want to be able to distinguish the new Scenario Test tool option, from the existing one, within the Asset list so that I can quickly/easily create a test using the new editor.
> *Verification conditions:*
> The new Scenario Test tool is distinguishable from the existing test tool within the asset list, through visual inspection by the user (no hover/click required.)
> Notes:
> Need a way to identify "experimental" tools from existing (to be deprecated?) tools. Solution might include distinct names for each, or parenthetical append (e.g. "experimental, beta, preview...) Or visual indicator, such as an icon, flag, etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (DROOLS-2706) New "Scenario Test" asset list option (UX)
by Stetson Robinson (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2706?page=com.atlassian.jira.plugi... ]
Stetson Robinson edited comment on DROOLS-2706 at 7/9/18 11:25 AM:
-------------------------------------------------------------------
[~ibek], what other assets besides rules will the scenario test then? Process simulations are separate from test scenarios, and I thought this was to replace test scenarios only.
Regarding the name, I think the word "Test" needs to be there because users know what a "test" is intuitively, but "simulation" takes some thought and interpretation. A "simulation" and a "test" mean close to the same thing in this context, so we should opt for the clearer term, which imo is "test". And we should not say "simulation test" or "test simulator", which are redundant. As I understand it, this feature is a way to test that a scenario of conditions yields the expected results based on the rules user's have created. So because of that, *Rule Scenario Test* or just *Scenario Test* or frankly the existing name *Test Scenario* makes the most sense to me.
Is there any reason why we don't just leave this feature called *Test Scenario* as it is? Why do we need to change the name and why does everyone keep suggesting "simulation" as part of it? We already have "Process Simulation" in the process designer as a separate feature, which I don't think this new feature will replace from what I understand. I assume I must be overlooking some aspect of this feature.
was (Author: stetson.robinson):
[~ibek], what other assets besides rules will the scenario test then?
Regarding the name, I think the word "Test" needs to be there because users know what a "test" is intuitively, but "simulation" takes some thought and interpretation. A "simulation" and a "test" mean close to the same thing in this context, so we should opt for the clearer term, which imo is "test". And we should not say "simulation test" or "test simulator", which are redundant. As I understand it, this feature is a way to test that a scenario of conditions yields the expected results based on the rules user's have created. So because of that, *Rule Scenario Test* or just *Scenario Test* or frankly the existing name *Test Scenario* makes the most sense to me.
Is there any reason why we don't just leave this feature called *Test Scenario* as it is? Why do we need to change the name and why does everyone keep suggesting "simulation" as part of it? I assume I must be overlooking some aspect of this feature.
> New "Scenario Test" asset list option (UX)
> ------------------------------------------
>
> Key: DROOLS-2706
> URL: https://issues.jboss.org/browse/DROOLS-2706
> Project: Drools
> Issue Type: Task
> Components: Scenario Simulation and Testing
> Reporter: Liz Clayton
> Assignee: Liz Clayton
> Labels: UX, UXTeam
>
> As a practitioner - I want to be able to distinguish the new Scenario Test tool option, from the existing one, within the Asset list so that I can quickly/easily create a test using the new editor.
> *Verification conditions:*
> The new Scenario Test tool is distinguishable from the existing test tool within the asset list, through visual inspection by the user (no hover/click required.)
> Notes:
> Need a way to identify "experimental" tools from existing (to be deprecated?) tools. Solution might include distinct names for each, or parenthetical append (e.g. "experimental, beta, preview...) Or visual indicator, such as an icon, flag, etc.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10288) Remove ee8.preview.mode support
by James Perkins (JIRA)
[ https://issues.jboss.org/browse/WFLY-10288?page=com.atlassian.jira.plugin... ]
James Perkins updated WFLY-10288:
---------------------------------
Description:
Once Java EE 8 compliant we need to remove the support for the {{ee8.preview.mode}} system property.
The following modules will need to be updated:
* -{{javax.enterprise.api}}-
* {{javax.validation.api}}
* -{{javax.json.bind.api}}-
* -{{javax.json.api}}-
* {{javax.annotation.api}}
* -{{javax.servlet.api}}-
* -{{org.wildfly.bridge.servlet-api-bridge}} (needs to be removed)-
* -{{org.eclipse.yasson}}-
* -{{org.glassfish.javax.json}}-
* {{javax.persistence.api}}
* -{{javax.ws.rs.api}}-
* {{javax.faces.api}}
* {{javax.mail.api}}
* {{javax.xml.bind.api}}
* -{{org.wildfly.cdi-api-bridge}}-
* -{{org.jboss.resteasy.resteasy-json-binding-provider}}-
* -{{org.jboss.resteasy.resteasy-jaxrs}}-
* {{org.hibernate.validator}}
* {{org.hibernate.validator.cdi}}
* {{org.hibernate}}
* {{com.sun.jsf-impl}}
The following configuration needs to be removed:
* {{./feature-pack/src/main/resources/configuration/standalone/template-ee8.xml}}
The Hibernate Search modules are currently duplicated:
* {{org.hibernate.search.*}} using "main" slot should be removed
* {{org.hibernate.search.*}} using "5.10" slot should be promoted to main
* Update usage of constants {{org.jboss.as.jpa.config.Configuration#PROVIDER_MODULE_HIBERNATE_SEARCH_EE8}}, PROVIDER_MODULE_HIBERNATE_SEARCH_EE7
The following source files should be updated:
* -{{org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.java}}-
* -{{org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.java}}-
Any solution for WFLY-10289 should be reverted.
The following documentation needs to be updated:
* {{./docs/src/main/asciidoc/Getting_Started_Guide.adoc}}
was:
Once Java EE 8 compliant we need to remove the support for the {{ee8.preview.mode}} system property.
The following modules will need to be updated:
* -{{javax.enterprise.api}}-
* {{javax.validation.api}}
* -{{javax.json.bind.api}}-
* -{{javax.json.api}}-
* {{javax.annotation.api}}
* -{{javax.servlet.api}}-
* -{{org.wildfly.bridge.servlet-api-bridge}} (needs to be removed)-
* -{{org.eclipse.yasson}}-
* -{{org.glassfish.javax.json}}-
* {{javax.persistence.api}}
* {{javax.ws.rs.api}}
* {{javax.faces.api}}
* {{javax.mail.api}}
* {{javax.xml.bind.api}}
* -{{org.wildfly.cdi-api-bridge}}-
* {{org.jboss.resteasy.resteasy-json-binding-provider}}
* {{org.jboss.resteasy.resteasy-jaxrs}}
* {{org.hibernate.validator}}
* {{org.hibernate.validator.cdi}}
* {{org.hibernate}}
* {{com.sun.jsf-impl}}
The following configuration needs to be removed:
* {{./feature-pack/src/main/resources/configuration/standalone/template-ee8.xml}}
The Hibernate Search modules are currently duplicated:
* {{org.hibernate.search.*}} using "main" slot should be removed
* {{org.hibernate.search.*}} using "5.10" slot should be promoted to main
* Update usage of constants {{org.jboss.as.jpa.config.Configuration#PROVIDER_MODULE_HIBERNATE_SEARCH_EE8}}, PROVIDER_MODULE_HIBERNATE_SEARCH_EE7
The following source files should be updated:
* -{{org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.java}}-
* -{{org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.java}}-
Any solution for WFLY-10289 should be reverted.
The following documentation needs to be updated:
* {{./docs/src/main/asciidoc/Getting_Started_Guide.adoc}}
> Remove ee8.preview.mode support
> -------------------------------
>
> Key: WFLY-10288
> URL: https://issues.jboss.org/browse/WFLY-10288
> Project: WildFly
> Issue Type: Sub-task
> Components: EE
> Reporter: James Perkins
> Assignee: James Perkins
> Fix For: 14.0.0.CR1
>
>
> Once Java EE 8 compliant we need to remove the support for the {{ee8.preview.mode}} system property.
> The following modules will need to be updated:
> * -{{javax.enterprise.api}}-
> * {{javax.validation.api}}
> * -{{javax.json.bind.api}}-
> * -{{javax.json.api}}-
> * {{javax.annotation.api}}
> * -{{javax.servlet.api}}-
> * -{{org.wildfly.bridge.servlet-api-bridge}} (needs to be removed)-
> * -{{org.eclipse.yasson}}-
> * -{{org.glassfish.javax.json}}-
> * {{javax.persistence.api}}
> * -{{javax.ws.rs.api}}-
> * {{javax.faces.api}}
> * {{javax.mail.api}}
> * {{javax.xml.bind.api}}
> * -{{org.wildfly.cdi-api-bridge}}-
> * -{{org.jboss.resteasy.resteasy-json-binding-provider}}-
> * -{{org.jboss.resteasy.resteasy-jaxrs}}-
> * {{org.hibernate.validator}}
> * {{org.hibernate.validator.cdi}}
> * {{org.hibernate}}
> * {{com.sun.jsf-impl}}
> The following configuration needs to be removed:
> * {{./feature-pack/src/main/resources/configuration/standalone/template-ee8.xml}}
> The Hibernate Search modules are currently duplicated:
> * {{org.hibernate.search.*}} using "main" slot should be removed
> * {{org.hibernate.search.*}} using "5.10" slot should be promoted to main
> * Update usage of constants {{org.jboss.as.jpa.config.Configuration#PROVIDER_MODULE_HIBERNATE_SEARCH_EE8}}, PROVIDER_MODULE_HIBERNATE_SEARCH_EE7
> The following source files should be updated:
> * -{{org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService.java}}-
> * -{{org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.java}}-
> Any solution for WFLY-10289 should be reverted.
> The following documentation needs to be updated:
> * {{./docs/src/main/asciidoc/Getting_Started_Guide.adoc}}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years