[JBoss JIRA] (WFWIP-182) OCP4 Operator doesn't react on env update
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFWIP-182?page=com.atlassian.jira.plugin.... ]
Petr Kremensky closed WFWIP-182.
--------------------------------
Resolution: Rejected
Sorry for false alarm, apparently the {{:last}} tag from a registry I store the operator was not pointing to the latest, running with Operator image build from https://github.com/wildfly/wildfly-operator/commit/467407a6c21102c77d95e9... forks fine.
> OCP4 Operator doesn't react on env update
> -----------------------------------------
>
> Key: WFWIP-182
> URL: https://issues.jboss.org/browse/WFWIP-182
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Brian Stansberry
> Priority: Blocker
>
> Updating env in WildFlyServerSpec is not reflected by Operator. The issue is specific to OCP4 (works fine on OCP3).
> Operator image build from https://github.com/wildfly/wildfly-operator/commit/467407a6c21102c77d95e9...
> *OpenShift Version:* 4.1.9
> *Actual:*
> * update of env do nothing with the statefulset configuration - no change on Wildfly pods
> *Expected:*
> * update of env create a new generation of statefulset and trigger rolling update of Wildfly pods
> Deploy the application using wildfly operator
> {code}
> $ cat wildfly-operator.yaml
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> name: wildfly-operator
> spec:
> applicationImage: "quay.io/wildfly/wildfly-centos7:17.0"
> env:
> - name: TEST_START
> value: INITIAL
> size: 1
> {code}
> Deploy and see the envs
> {code}
> oc apply -f wildfly-operator.yaml
> oc set env pod/wildfly-operator-0 --list | grep TEST
> TEST_START=INITIAL
> {code}
> Use oc client to edit the env (e.g. modify the env key & value)
> {code}
> oc edit wildflyserver wildfly-operator
> env:
> - name: TEST_UPDATE
> value: UPDATE
> {code}
> Notice a new generation of operator is created, {color:red}but no new generation of statefulset{color} - no update to pods.
> {code}
> $ oc get wildflyserver wildfly-operator -o yaml | grep generation
> generation: 2
> $ oc get statefulset.apps/wildfly-operator -o yaml | grep generation
> generation: 1
> $ oc set env pod/wildfly-operator-0 --list | grep TEST
> TEST_START=INITIAL
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 11 months
[JBoss JIRA] (WFWIP-182) OCP4 Operator doesn't react on env update
by Petr Kremensky (Jira)
Petr Kremensky created WFWIP-182:
------------------------------------
Summary: OCP4 Operator doesn't react on env update
Key: WFWIP-182
URL: https://issues.jboss.org/browse/WFWIP-182
Project: WildFly WIP
Issue Type: Bug
Components: OpenShift
Reporter: Petr Kremensky
Assignee: Brian Stansberry
Updating env in WildFlyServerSpec is not reflected by Operator. The issue is specific to OCP4 (works fine on OCP3).
Operator image build from https://github.com/wildfly/wildfly-operator/commit/467407a6c21102c77d95e9...
*OpenShift Version:* 4.1.9
**Actual:**
* update of env do nothing with the statefulset configuration - no change on Wildfly pods
**Expected:**
* update of env create a new generation of statefulset and trigger rolling update of Wildfly pods
Deploy the application using wildfly operator
{code}
$ cat wildfly-operator.yaml
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: wildfly-operator
spec:
applicationImage: "quay.io/wildfly/wildfly-centos7:17.0"
env:
- name: TEST_START
value: INITIAL
size: 1
{code}
Deploy and see the envs
{code}
oc apply -f wildfly-operator.yaml
oc set env pod/wildfly-operator-0 --list | grep TEST
TEST_START=INITIAL
{code}
Use oc client to edit the env (e.g. modify the env key & value)
{code}
oc edit wildflyserver wildfly-operator
env:
- name: TEST_UPDATE
value: UPDATE
{code}
Notice a new generation of operator is created, {color:red}but no new generation of statefulset{color} - no update to pods.
{code}
$ oc get wildflyserver wildfly-operator -o yaml | grep generation
generation: 2
$ oc get statefulset.apps/wildfly-operator -o yaml | grep generation
generation: 1
$ oc set env pod/wildfly-operator-0 --list | grep TEST
TEST_START=INITIAL
{code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 11 months
[JBoss JIRA] (WFWIP-182) OCP4 Operator doesn't react on env update
by Petr Kremensky (Jira)
[ https://issues.jboss.org/browse/WFWIP-182?page=com.atlassian.jira.plugin.... ]
Petr Kremensky updated WFWIP-182:
---------------------------------
Description:
Updating env in WildFlyServerSpec is not reflected by Operator. The issue is specific to OCP4 (works fine on OCP3).
Operator image build from https://github.com/wildfly/wildfly-operator/commit/467407a6c21102c77d95e9...
*OpenShift Version:* 4.1.9
*Actual:*
* update of env do nothing with the statefulset configuration - no change on Wildfly pods
*Expected:*
* update of env create a new generation of statefulset and trigger rolling update of Wildfly pods
Deploy the application using wildfly operator
{code}
$ cat wildfly-operator.yaml
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: wildfly-operator
spec:
applicationImage: "quay.io/wildfly/wildfly-centos7:17.0"
env:
- name: TEST_START
value: INITIAL
size: 1
{code}
Deploy and see the envs
{code}
oc apply -f wildfly-operator.yaml
oc set env pod/wildfly-operator-0 --list | grep TEST
TEST_START=INITIAL
{code}
Use oc client to edit the env (e.g. modify the env key & value)
{code}
oc edit wildflyserver wildfly-operator
env:
- name: TEST_UPDATE
value: UPDATE
{code}
Notice a new generation of operator is created, {color:red}but no new generation of statefulset{color} - no update to pods.
{code}
$ oc get wildflyserver wildfly-operator -o yaml | grep generation
generation: 2
$ oc get statefulset.apps/wildfly-operator -o yaml | grep generation
generation: 1
$ oc set env pod/wildfly-operator-0 --list | grep TEST
TEST_START=INITIAL
{code}
was:
Updating env in WildFlyServerSpec is not reflected by Operator. The issue is specific to OCP4 (works fine on OCP3).
Operator image build from https://github.com/wildfly/wildfly-operator/commit/467407a6c21102c77d95e9...
*OpenShift Version:* 4.1.9
**Actual:**
* update of env do nothing with the statefulset configuration - no change on Wildfly pods
**Expected:**
* update of env create a new generation of statefulset and trigger rolling update of Wildfly pods
Deploy the application using wildfly operator
{code}
$ cat wildfly-operator.yaml
apiVersion: wildfly.org/v1alpha1
kind: WildFlyServer
metadata:
name: wildfly-operator
spec:
applicationImage: "quay.io/wildfly/wildfly-centos7:17.0"
env:
- name: TEST_START
value: INITIAL
size: 1
{code}
Deploy and see the envs
{code}
oc apply -f wildfly-operator.yaml
oc set env pod/wildfly-operator-0 --list | grep TEST
TEST_START=INITIAL
{code}
Use oc client to edit the env (e.g. modify the env key & value)
{code}
oc edit wildflyserver wildfly-operator
env:
- name: TEST_UPDATE
value: UPDATE
{code}
Notice a new generation of operator is created, {color:red}but no new generation of statefulset{color} - no update to pods.
{code}
$ oc get wildflyserver wildfly-operator -o yaml | grep generation
generation: 2
$ oc get statefulset.apps/wildfly-operator -o yaml | grep generation
generation: 1
$ oc set env pod/wildfly-operator-0 --list | grep TEST
TEST_START=INITIAL
{code}
> OCP4 Operator doesn't react on env update
> -----------------------------------------
>
> Key: WFWIP-182
> URL: https://issues.jboss.org/browse/WFWIP-182
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Petr Kremensky
> Assignee: Brian Stansberry
> Priority: Blocker
>
> Updating env in WildFlyServerSpec is not reflected by Operator. The issue is specific to OCP4 (works fine on OCP3).
> Operator image build from https://github.com/wildfly/wildfly-operator/commit/467407a6c21102c77d95e9...
> *OpenShift Version:* 4.1.9
> *Actual:*
> * update of env do nothing with the statefulset configuration - no change on Wildfly pods
> *Expected:*
> * update of env create a new generation of statefulset and trigger rolling update of Wildfly pods
> Deploy the application using wildfly operator
> {code}
> $ cat wildfly-operator.yaml
> apiVersion: wildfly.org/v1alpha1
> kind: WildFlyServer
> metadata:
> name: wildfly-operator
> spec:
> applicationImage: "quay.io/wildfly/wildfly-centos7:17.0"
> env:
> - name: TEST_START
> value: INITIAL
> size: 1
> {code}
> Deploy and see the envs
> {code}
> oc apply -f wildfly-operator.yaml
> oc set env pod/wildfly-operator-0 --list | grep TEST
> TEST_START=INITIAL
> {code}
> Use oc client to edit the env (e.g. modify the env key & value)
> {code}
> oc edit wildflyserver wildfly-operator
> env:
> - name: TEST_UPDATE
> value: UPDATE
> {code}
> Notice a new generation of operator is created, {color:red}but no new generation of statefulset{color} - no update to pods.
> {code}
> $ oc get wildflyserver wildfly-operator -o yaml | grep generation
> generation: 2
> $ oc get statefulset.apps/wildfly-operator -o yaml | grep generation
> generation: 1
> $ oc set env pod/wildfly-operator-0 --list | grep TEST
> TEST_START=INITIAL
> {code}
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 11 months
[JBoss JIRA] (WFLY-12063) ClassFormatError on JDK13
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFLY-12063?page=com.atlassian.jira.plugin... ]
Richard Opalka commented on WFLY-12063:
---------------------------------------
[~brian.stansberry] [~gbadner] [~smarlow] If Hibernate team for any reason will not release Hibernate with upgraded Bytebuddy on time
there's still alternative to revert WFLY-11891 (test changes that introduced this regression):
https://github.com/ropalka/wildfly/commit/cbdfa9aaff6a73ec3852a2209ef937a...
> ClassFormatError on JDK13
> -------------------------
>
> Key: WFLY-12063
> URL: https://issues.jboss.org/browse/WFLY-12063
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Richard Opalka
> Assignee: Scott Marlow
> Priority: Critical
> Labels: blocker-WF18, jdk13
> Attachments: server.log, test.log
>
>
> The following commit https://github.com/wildfly/wildfly/commit/b6d141b06404a4c23ead1d04d6e26fc... introduced JDK13 regression in WildFly.
> Affected tests are:
> ---
> [ERROR] Errors:
> [ERROR] MultiplePuTestCase.org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase » Deployment
> [ERROR] EntityListenersTestCase.org.jboss.as.test.integration.jpa.entitylistener.EntityListenersTestCase » Deployment
> [ERROR] EPCPropagationTestCase.org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase » Deployment
> [ERROR] AuditJoinTableoverBidirectionalTest.org.jboss.as.test.integration.jpa.hibernate.envers.AuditJoinTableoverBidirectionalTest » Deployment
> [ERROR] AuditJoinTableoverOnetoManyJoinColumnTest.org.jboss.as.test.integration.jpa.hibernate.envers.AuditJoinTableoverOnetoManyJoinColumnTest » Deployment
> [ERROR] ManagementTestCase.getEntityInsertCountAttribute:98 » Deployment Cannot deploy...
> [ERROR] JPA2LCTestCase.org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase » Deployment
> [ERROR] JpaStatisticsTestCase.org.jboss.as.test.integration.jpa.secondlevelcache.JpaStatisticsTestCase » Deployment
> [ERROR] TransactionTestCase.org.jboss.as.test.integration.jpa.transaction.TransactionTestCase » Deployment
> [INFO]
> [ERROR] Tests run: 1553, Failures: 0, Errors: 9, Skipped: 14
> ---
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 11 months
[JBoss JIRA] (WFLY-12063) ClassFormatError on JDK13
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFLY-12063?page=com.atlassian.jira.plugin... ]
Richard Opalka edited comment on WFLY-12063 at 8/27/19 6:25 AM:
----------------------------------------------------------------
[~brian.stansberry] [~gbadner] [~smarlow] If Hibernate team for any reason will not release Hibernate with upgraded Bytebuddy on time
there's still alternative to revert WFLY-11891 (test changes that introduced this regression):
https://github.com/ropalka/wildfly/commit/cbdfa9aaff6a73ec3852a2209ef937a...
and then again *revert this revert* after WF 18.Final tag :)
was (Author: ropalka):
[~brian.stansberry] [~gbadner] [~smarlow] If Hibernate team for any reason will not release Hibernate with upgraded Bytebuddy on time
there's still alternative to revert WFLY-11891 (test changes that introduced this regression):
https://github.com/ropalka/wildfly/commit/cbdfa9aaff6a73ec3852a2209ef937a...
> ClassFormatError on JDK13
> -------------------------
>
> Key: WFLY-12063
> URL: https://issues.jboss.org/browse/WFLY-12063
> Project: WildFly
> Issue Type: Bug
> Components: JPA / Hibernate
> Reporter: Richard Opalka
> Assignee: Scott Marlow
> Priority: Critical
> Labels: blocker-WF18, jdk13
> Attachments: server.log, test.log
>
>
> The following commit https://github.com/wildfly/wildfly/commit/b6d141b06404a4c23ead1d04d6e26fc... introduced JDK13 regression in WildFly.
> Affected tests are:
> ---
> [ERROR] Errors:
> [ERROR] MultiplePuTestCase.org.jboss.as.test.integration.jpa.basic.multiplepersistenceunittest.MultiplePuTestCase » Deployment
> [ERROR] EntityListenersTestCase.org.jboss.as.test.integration.jpa.entitylistener.EntityListenersTestCase » Deployment
> [ERROR] EPCPropagationTestCase.org.jboss.as.test.integration.jpa.epcpropagation.EPCPropagationTestCase » Deployment
> [ERROR] AuditJoinTableoverBidirectionalTest.org.jboss.as.test.integration.jpa.hibernate.envers.AuditJoinTableoverBidirectionalTest » Deployment
> [ERROR] AuditJoinTableoverOnetoManyJoinColumnTest.org.jboss.as.test.integration.jpa.hibernate.envers.AuditJoinTableoverOnetoManyJoinColumnTest » Deployment
> [ERROR] ManagementTestCase.getEntityInsertCountAttribute:98 » Deployment Cannot deploy...
> [ERROR] JPA2LCTestCase.org.jboss.as.test.integration.jpa.secondlevelcache.JPA2LCTestCase » Deployment
> [ERROR] JpaStatisticsTestCase.org.jboss.as.test.integration.jpa.secondlevelcache.JpaStatisticsTestCase » Deployment
> [ERROR] TransactionTestCase.org.jboss.as.test.integration.jpa.transaction.TransactionTestCase » Deployment
> [INFO]
> [ERROR] Tests run: 1553, Failures: 0, Errors: 9, Skipped: 14
> ---
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 11 months
[JBoss JIRA] (WFLY-12429) MockitoException in InfinispanBeanTestCase on latest JDK13
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFLY-12429?page=com.atlassian.jira.plugin... ]
Richard Opalka commented on WFLY-12429:
---------------------------------------
Added jdk13 label to known issues [~brian.stansberry]
> MockitoException in InfinispanBeanTestCase on latest JDK13
> ----------------------------------------------------------
>
> Key: WFLY-12429
> URL: https://issues.jboss.org/browse/WFLY-12429
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Richard Opalka
> Assignee: Paul Ferraro
> Priority: Major
> Labels: jdk13
> Fix For: 18.0.0.Beta1
>
>
> [INFO] Running org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase
> [ERROR] Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.929 s <<< FAILURE! - in org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase
> [ERROR] isExpired(org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase) Time elapsed: 0.027 s <<< ERROR!
> org.mockito.exceptions.base.MockitoException:
> Cannot call abstract real method on java object!
> Calling real methods is only possible when mocking non abstract method.
> //correct example:
> when(mockOfConcreteClass.nonAbstractMethod()).thenCallRealMethod();
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase.isExpired(InfinispanBeanTestCase.java:104)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 11 months
[JBoss JIRA] (WFLY-12429) MockitoException in InfinispanBeanTestCase on latest JDK13
by Richard Opalka (Jira)
[ https://issues.jboss.org/browse/WFLY-12429?page=com.atlassian.jira.plugin... ]
Richard Opalka updated WFLY-12429:
----------------------------------
Labels: jdk13 (was: )
> MockitoException in InfinispanBeanTestCase on latest JDK13
> ----------------------------------------------------------
>
> Key: WFLY-12429
> URL: https://issues.jboss.org/browse/WFLY-12429
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Reporter: Richard Opalka
> Assignee: Paul Ferraro
> Priority: Major
> Labels: jdk13
> Fix For: 18.0.0.Beta1
>
>
> [INFO] Running org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase
> [ERROR] Tests run: 7, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.929 s <<< FAILURE! - in org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase
> [ERROR] isExpired(org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase) Time elapsed: 0.027 s <<< ERROR!
> org.mockito.exceptions.base.MockitoException:
> Cannot call abstract real method on java object!
> Calling real methods is only possible when mocking non abstract method.
> //correct example:
> when(mockOfConcreteClass.nonAbstractMethod()).thenCallRealMethod();
> at org.wildfly.clustering.ejb.infinispan.bean.InfinispanBeanTestCase.isExpired(InfinispanBeanTestCase.java:104)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.base/java.lang.reflect.Method.invoke(Method.java:567)
> at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:273)
> at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:383)
> at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:344)
> at org.apache.maven.surefire.booter.ForkedBooter.execute(ForkedBooter.java:125)
> at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:417)
--
This message was sent by Atlassian Jira
(v7.13.5#713005)
6 years, 11 months