[JBoss JIRA] (DROOLS-1609) Augment FEEL AST node at compilation with return type
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1609?page=com.atlassian.jira.plugi... ]
Kris Verlaenen updated DROOLS-1609:
-----------------------------------
Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06, 2018 Week 07-08 (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06)
> Augment FEEL AST node at compilation with return type
> -----------------------------------------------------
>
> Key: DROOLS-1609
> URL: https://issues.jboss.org/browse/DROOLS-1609
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
> Priority: Minor
>
> This is needed so to be able to determine the result of a boxed function at compile time, in turn to be able at compile time to determine a valid compilation without error of a BKM for instance.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-1946) DMN Editor
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1946?page=com.atlassian.jira.plugi... ]
Kris Verlaenen updated DROOLS-1946:
-----------------------------------
Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06, 2018 Week 07-08 (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06)
> DMN Editor
> ----------
>
> Key: DROOLS-1946
> URL: https://issues.jboss.org/browse/DROOLS-1946
> Project: Drools
> Issue Type: Feature Request
> Components: DMN Editor
> Reporter: Michael Anstis
> Assignee: Michael Anstis
> Labels: UX
> Fix For: 7.7.0.Final
>
>
> Place holder for all DMN Editor related activities
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2118) DMN extension REST /dmn to list inputData and itemDefs
by Kris Verlaenen (JIRA)
[ https://issues.jboss.org/browse/DROOLS-2118?page=com.atlassian.jira.plugi... ]
Kris Verlaenen updated DROOLS-2118:
-----------------------------------
Sprint: 2018 Week 05-06, 2018 Week 07-08 (was: 2018 Week 05-06)
> DMN extension REST /dmn to list inputData and itemDefs
> ------------------------------------------------------
>
> Key: DROOLS-2118
> URL: https://issues.jboss.org/browse/DROOLS-2118
> Project: Drools
> Issue Type: Enhancement
> Components: dmn engine, kie server
> Reporter: Matteo Mortari
> Assignee: Matteo Mortari
>
> Currently /dmn enlist the model coordinates and the list of DMN Decisions.
> In order to be more complete from a client perspective, it is also required for it to enlist:
> * the list of DMN InputData, so to know which inputs are required for the model evaluation
> * the ItemDefinitions so to know of which types are the inputs
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9801) Wsprovide tool ends with java.security.AccessControlException
by Marek Kopecký (JIRA)
Marek Kopecký created WFLY-9801:
-----------------------------------
Summary: Wsprovide tool ends with java.security.AccessControlException
Key: WFLY-9801
URL: https://issues.jboss.org/browse/WFLY-9801
Project: WildFly
Issue Type: Bug
Components: Scripts, Web Services
Reporter: Marek Kopecký
Assignee: Alessio Soldano
Priority: Blocker
Attachments: Echo1.class, Echo1Impl.class
*Description of the issue:*
wsprovide tool ends with java.security.AccessControlException
I see this issue on WF master (2018_02_12). This is regression against WF master from 2018_02_05, so priority of this jira is blocker.
*How reproducible:*
Always
*Steps to Reproduce:*
# Use these (class files are attached):
{code:java}
@WebService(endpointInterface = "org.jboss.as.testsuite.integration.scripts.test.tools.Echo1", targetNamespace = "org.jboss.as.testsuite.integration.scripts.test.tools", serviceName = "Echo1Service")
public class Echo1Impl implements Echo1 {
@Override
public String echoPlus1(String s) {
return s + "1";
}
}
{code}
{code:java}
@WebService
@SOAPBinding
public interface Echo1 {
String echoPlus1(String s);
}
{code}
# cd $\{JBOSS_HOME\}/bin
# mkdir out
# ./wsprovide.sh -k -c $\{CLASS_DIR\} -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
*Actual results:*
{noformat}
[mkopecky@localhost bin]$ ./wsprovide.sh -k -c ~/erase2 -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
Could not find log4j.properties or log4j.xml configuration, logging to console.
java2ws -s /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -classdir /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -d /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -verbose -cp /home/mkopecky/erase2/: -wrapperbean -createxsdimports org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
java2ws - Apache CXF 3.2.2
java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out/org/jboss/as/testsuite/integration/scripts/test/tools/jaxws/EchoPlus1Response.java" "read")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at java.io.File.isDirectory(File.java:844)
at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:69)
at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:64)
at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromFiles(JavacFileManager.java:785)
at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromStrings(JavacFileManager.java:185)
at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:202)
at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:141)
at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generateAndCompile(BeanGenerator.java:91)
at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:58)
at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:35)
at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.generate(JavaToWSDLProcessor.java:156)
at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.process(JavaToWSDLProcessor.java:118)
at org.apache.cxf.tools.java2ws.JavaToWSContainer.processWSDL(JavaToWSContainer.java:110)
at org.apache.cxf.tools.java2ws.JavaToWSContainer.execute(JavaToWSContainer.java:75)
at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:45)
at org.apache.cxf.tools.java2ws.JavaToWS.run(JavaToWS.java:83)
at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:200)
at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:109)
at org.jboss.ws.tools.cmd.WSProvide.generate(WSProvide.java:223)
at org.jboss.ws.tools.cmd.WSProvide.main(WSProvide.java:89)
at org.jboss.modules.Module.runMainMethod(Module.java:348)
at org.jboss.modules.Module.run(Module.java:328)
at org.jboss.modules.Main.main(Main.java:557)
{noformat}
*Expected results:*
No errors
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9801) Wsprovide tool ends with java.security.AccessControlException
by Marek Kopecký (JIRA)
[ https://issues.jboss.org/browse/WFLY-9801?page=com.atlassian.jira.plugin.... ]
Marek Kopecký updated WFLY-9801:
--------------------------------
Attachment: Echo1.class
Echo1Impl.class
> Wsprovide tool ends with java.security.AccessControlException
> -------------------------------------------------------------
>
> Key: WFLY-9801
> URL: https://issues.jboss.org/browse/WFLY-9801
> Project: WildFly
> Issue Type: Bug
> Components: Scripts, Web Services
> Reporter: Marek Kopecký
> Assignee: Alessio Soldano
> Priority: Blocker
> Attachments: Echo1.class, Echo1Impl.class
>
>
> *Description of the issue:*
> wsprovide tool ends with java.security.AccessControlException
> I see this issue on WF master (2018_02_12). This is regression against WF master from 2018_02_05, so priority of this jira is blocker.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # Use these (class files are attached):
> {code:java}
> @WebService(endpointInterface = "org.jboss.as.testsuite.integration.scripts.test.tools.Echo1", targetNamespace = "org.jboss.as.testsuite.integration.scripts.test.tools", serviceName = "Echo1Service")
> public class Echo1Impl implements Echo1 {
> @Override
> public String echoPlus1(String s) {
> return s + "1";
> }
> }
> {code}
> {code:java}
> @WebService
> @SOAPBinding
> public interface Echo1 {
> String echoPlus1(String s);
> }
> {code}
> # cd $\{JBOSS_HOME\}/bin
> # mkdir out
> # ./wsprovide.sh -k -c $\{CLASS_DIR\} -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> *Actual results:*
> {noformat}
> [mkopecky@localhost bin]$ ./wsprovide.sh -k -c ~/erase2 -o out org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> Could not find log4j.properties or log4j.xml configuration, logging to console.
> java2ws -s /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -classdir /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -d /home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out -verbose -cp /home/mkopecky/erase2/: -wrapperbean -createxsdimports org.jboss.as.testsuite.integration.scripts.test.tools.Echo1Impl
> java2ws - Apache CXF 3.2.2
> java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.13/wfly.13/bin/out/org/jboss/as/testsuite/integration/scripts/test/tools/jaxws/EchoPlus1Response.java" "read")
> at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> at java.security.AccessController.checkPermission(AccessController.java:884)
> at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> at java.io.File.isDirectory(File.java:844)
> at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:69)
> at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:64)
> at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromFiles(JavacFileManager.java:785)
> at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromStrings(JavacFileManager.java:185)
> at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:202)
> at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:141)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generateAndCompile(BeanGenerator.java:91)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:58)
> at org.apache.cxf.tools.java2wsdl.generator.wsdl11.BeanGenerator.generate(BeanGenerator.java:35)
> at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.generate(JavaToWSDLProcessor.java:156)
> at org.apache.cxf.tools.java2wsdl.processor.JavaToWSDLProcessor.process(JavaToWSDLProcessor.java:118)
> at org.apache.cxf.tools.java2ws.JavaToWSContainer.processWSDL(JavaToWSContainer.java:110)
> at org.apache.cxf.tools.java2ws.JavaToWSContainer.execute(JavaToWSContainer.java:75)
> at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:45)
> at org.apache.cxf.tools.java2ws.JavaToWS.run(JavaToWS.java:83)
> at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:200)
> at org.jboss.wsf.stack.cxf.tools.CXFProviderImpl.provide(CXFProviderImpl.java:109)
> at org.jboss.ws.tools.cmd.WSProvide.generate(WSProvide.java:223)
> at org.jboss.ws.tools.cmd.WSProvide.main(WSProvide.java:89)
> at org.jboss.modules.Module.runMainMethod(Module.java:348)
> at org.jboss.modules.Module.run(Module.java:328)
> at org.jboss.modules.Main.main(Main.java:557)
> {noformat}
> *Expected results:*
> No errors
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3556) Unexpected output with grep '^no\(fork\|group\)'
by Marek Marusic (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3556?page=com.atlassian.jira.plugi... ]
Marek Marusic edited comment on WFCORE-3556 at 2/12/18 7:31 AM:
----------------------------------------------------------------
It looks like the problem is caused because of the escape characters.
I tried it with *grep command in linux bash* environment :
$ echo nofork | grep '^no(fork|group)' #no output, since characters (|) are not escaped.
$ echo nofork | grep '^no\(fork\|group\)' #finds the match, since characters (|) are escaped.
nofork
\\
And then I tried it with the *grep* command from *aesh-extensions* the behaviour is exactly opposite:
\[aesh@extensions\] $ echo nofork | grep '^no\(fork\|group\)' #no match
\[aesh@extensions\] $ echo nofork | grep '^no(fork|group)' #finds a match
nofork
\\
Do you [~kanovotn] [~jdenise] think this is wrong behaviour and the grep from aesh-extensions should behave exactly the same as the bash and therefore it should expect the escaped regex *'^no\(fork\|group\)'* ?
was (Author: mmarusic):
It looks like the problem is caused because of the escape characters.
I tried it with *grep command in linux bash* environment :
$ echo nofork | grep '^no(fork|group)' #no output, since characters (|) are not escaped.
$ echo nofork | grep '^no\(fork\|group\)' #finds the match, since characters (|) are escaped.
nofork
And then I tried it with the *grep* command from *aesh-extensions* the behaviour is exactly opposite:
\[aesh@extensions\] $ echo nofork | grep '^no\(fork\|group\)' #no match
\[aesh@extensions\] $ echo nofork | grep '^no(fork|group)' #finds a match
nofork
Do you [~kanovotn] [~jdenise] think this is wrong behaviour and the grep from aesh-extensions should behave exactly the same as the bash and therefore it should expect the escaped regex *'^no\(fork\|group\)'* ?
> Unexpected output with grep '^no\(fork\|group\)'
> ------------------------------------------------
>
> Key: WFCORE-3556
> URL: https://issues.jboss.org/browse/WFCORE-3556
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Katerina Novotna
> Assignee: Jean-Francois Denise
>
> *Description of problem:*
> Aesh grep command doesn't return expected result. The same command with bash grep gives 'nofork' result.
> *Actual results:*
> [standalone@embedded /] echo nofork | grep '^no\(fork\|group\)'
> [standalone@embedded /]
> *Expected results:*
> [standalone@embedded /] echo nofork | grep '^no\(fork\|group\)'
> [standalone@embedded /] nofork
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3556) Unexpected output with grep '^no\(fork\|group\)'
by Marek Marusic (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3556?page=com.atlassian.jira.plugi... ]
Marek Marusic edited comment on WFCORE-3556 at 2/12/18 7:30 AM:
----------------------------------------------------------------
It looks like the problem is caused because of the escape characters.
I tried it with *grep command in linux bash* environment :
$ echo nofork | grep '^no(fork|group)' #no output, since characters (|) are not escaped.
$ echo nofork | grep '^no\(fork\|group\)' #finds the match, since characters (|) are escaped.
nofork
And then I tried it with the *grep* command from *aesh-extensions* the behaviour is exactly opposite:
\[aesh@extensions\] $ echo nofork | grep '^no\(fork\|group\)' #no match
\[aesh@extensions\] $ echo nofork | grep '^no(fork|group)' #finds a match
nofork
Do you [~kanovotn] [~jdenise] think this is wrong behaviour and the grep from aesh-extensions should behave exactly the same as the bash and therefore it should expect the escaped regex *'^no\(fork\|group\)'* ?
was (Author: mmarusic):
It looks like the problem is caused because of the escape characters.
I tried it with *grep command in linux bash* environment :
$ echo nofork | grep '^no(fork|group)' #no output, since characters (|) are not escaped.
$ echo nofork | grep '^no\(fork\|group\)' #finds the match, since characters (|) are escaped.
nofork
And then I tried it with the *grep* command from *aesh-extensions* the behaviour is exactly opposite:
\[aesh@extensions\] $ echo nofork | grep '^no\(fork\|group\)' #no match
\[aesh@extensions\] $ echo nofork | grep '^no(fork|group)' #finds a match
nofork
Do you [~kanovotn] [~jdenise] think this is wrong behaviour and the grep from aesh-extensions should behave exactly the same as the bash and therefore it should expect the escaped regex *'^no\(fork\|group\)'* ?
> Unexpected output with grep '^no\(fork\|group\)'
> ------------------------------------------------
>
> Key: WFCORE-3556
> URL: https://issues.jboss.org/browse/WFCORE-3556
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Katerina Novotna
> Assignee: Jean-Francois Denise
>
> *Description of problem:*
> Aesh grep command doesn't return expected result. The same command with bash grep gives 'nofork' result.
> *Actual results:*
> [standalone@embedded /] echo nofork | grep '^no\(fork\|group\)'
> [standalone@embedded /]
> *Expected results:*
> [standalone@embedded /] echo nofork | grep '^no\(fork\|group\)'
> [standalone@embedded /] nofork
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFCORE-3556) Unexpected output with grep '^no\(fork\|group\)'
by Marek Marusic (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3556?page=com.atlassian.jira.plugi... ]
Marek Marusic commented on WFCORE-3556:
---------------------------------------
It looks like the problem is caused because of the escape characters.
I tried it with *grep command in linux bash* environment :
$ echo nofork | grep '^no(fork|group)' #no output, since characters (|) are not escaped.
$ echo nofork | grep '^no\(fork\|group\)' #finds the match, since characters (|) are escaped.
nofork
And then I tried it with the *grep* command from *aesh-extensions* the behaviour is exactly opposite:
\[aesh@extensions\] $ echo nofork | grep '^no\(fork\|group\)' #no match
\[aesh@extensions\] $ echo nofork | grep '^no(fork|group)' #finds a match
nofork
Do you [~kanovotn] [~jdenise] think this is wrong behaviour and the grep from aesh-extensions should behave exactly the same as the bash and therefore it should expect the escaped regex *'^no\(fork\|group\)'* ?
> Unexpected output with grep '^no\(fork\|group\)'
> ------------------------------------------------
>
> Key: WFCORE-3556
> URL: https://issues.jboss.org/browse/WFCORE-3556
> Project: WildFly Core
> Issue Type: Bug
> Components: CLI
> Reporter: Katerina Novotna
> Assignee: Jean-Francois Denise
>
> *Description of problem:*
> Aesh grep command doesn't return expected result. The same command with bash grep gives 'nofork' result.
> *Actual results:*
> [standalone@embedded /] echo nofork | grep '^no\(fork\|group\)'
> [standalone@embedded /]
> *Expected results:*
> [standalone@embedded /] echo nofork | grep '^no\(fork\|group\)'
> [standalone@embedded /] nofork
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (DROOLS-2316) wrong ordering of ItemDefinition for compilation
by Matteo Mortari (JIRA)
Matteo Mortari created DROOLS-2316:
--------------------------------------
Summary: wrong ordering of ItemDefinition for compilation
Key: DROOLS-2316
URL: https://issues.jboss.org/browse/DROOLS-2316
Project: Drools
Issue Type: Bug
Components: dmn engine
Reporter: Matteo Mortari
Assignee: Matteo Mortari
The following exhibit the issue in the dmn compiler:
{code:java}
@Test
public void test3() {
ItemDefinition tNumberList = build("tNumberList");
ItemDefinition tTax = build("tTax");
ItemDefinition tStateModel = build("tStateModel");
ItemDefinition tTaxList = build("tTaxList", tTax);
ItemDefinition tCategory = build("tCategory");
ItemDefinition tItem = build("tItem", tCategory);
ItemDefinition tItemList = build("tItemList", tItem);
ItemDefinition tOrder = build("tOrder", tItemList);
List<ItemDefinition> originalList = Arrays.asList(new ItemDefinition[]{
tOrder,
tItem,
tCategory,
tNumberList,
tItemList,
tTax,
tStateModel,
tTaxList
});
List<ItemDefinition> orderedList = orderingStrategy(originalList);
assertTrue("Index of tCategory < tItem", orderedList.indexOf(tCategory) < orderedList.indexOf(tItem));
assertTrue("Index of tItem < tItemList", orderedList.indexOf(tItem) < orderedList.indexOf(tItemList));
assertTrue("Index of tItemList < tOrder", orderedList.indexOf(tItemList) < orderedList.indexOf(tOrder));
assertTrue("Index of tTax < tTaxList", orderedList.indexOf(tTax) < orderedList.indexOf(tTaxList));
}
{code}
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months