> Furthermore I can run those
(even without flag, just by 'mvn clean verify') locally
The -Dusage_reporting_enabled=false flag is set in the parent
pom for all JBT tests.
It helps for all the tests except for the usage tests on
Linux/Kepler M6.
Try to create parent pom that doesn't set this flag. You will be
able to reproduce the issue on Windows too.
On 4/5/2013 11:07 PM, André Dietisheim wrote:
On 04/05/2013 10:08 PM, Snjezana
Peco wrote:
A
test doesn't have to be an UI test to open the
UsageReportEnablementDialog dialog.
The dialog is created using the startup extension point.
That's why the usage plugin will always try to open this
dialog.
hmm, I looked at the patch and the test. To me the integration
test is using fakes and I therefore dont see where the test
would trigger the dialog.
The usage plugin triggers the dialog using the
org.eclipse.ui.startup extension point.
I
tend to think that the Eclipse runtime that is running the test
has the plugin installed and opens the dialog independently of
the tests. Thus I thinking that the flag (
-
Dusage_reporting_enabled=false) is not working properly? Or some
similar explanation... wrong?
The flag works properly. I have debugged the usage tests. The flag
is false before starting the usage tests and true after finishing
them. Kepler M6 runs the tests and, after that, calls the dialog.
The patch fixes the issue by resetting the flag after finishing
the tests and before calling the dialog.
Snjeza
The
issue can't be reproduced on Windows. It can always be
reproduced on Linux when using Kepler M6. Not sure for Mac.
The issue isn't caused by changes in usage/JBT, but in Kepler
M6.
Snjeza
On 4/5/2013 9:28 PM, André Dietisheim wrote:
On 04/05/2013 09:00 PM, Nick Boldt
wrote:
Isn't there a commandline flag to
suppress that so that the test DOES
NOT block until timeout?
As far as I can say the flag is only suppressing the usage
in SWTBot-Test where a UI is actually run. The usage test
are not running UI, thus the flag has no effect on them.
Furthermore I can run those (even without flag, just by 'mvn
clean verify') locally and they run perfectly smooth.
[INFO] usage.tests .......................................
SUCCESS [0.004s]
[INFO] org.jboss.tools.usage.test ........................
SUCCESS [10.156s]
There was 0 change in usage since Alpha1 (and even before)
so I wonder why this should now fail?
I have to test with Kepler TP though.
On 04/05/2013 02:56 PM, Snjezana Peco wrote:
Yes, they do.
Snjeza
On 4/5/2013 8:41 PM, Nick Boldt wrote:
Do the usage tests involve
waiting for a user to click the dialog
asking if it's OK to collect anonymous usage stats?
N
On 04/05/2013 02:19 PM, Snjezana Peco wrote:
See https://issues.jboss.org/browse/JBIDE-13939
and
https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/JBossTools/view/JBossTools_Trunk/job/jbosstools-base_master/220/console
The usage tests take 1.02 sec, but freeze.
Snjeza
On 4/3/2013 9:33 PM, Snjezana Peco wrote:
I have created JBIDE-13908,
JBIDE-13910, JBIDE-13911 and reopened
JBIDE-13733. They are related to tests.
Snjeza
On 4/3/2013 6:30 PM, Nick Boldt wrote:
As code freeze is
tomorrow, it's that time of the month where I
have the
pleasure of sending reminder note that if your
job is red or yellow,
*you need to fix your tests*.
Here are today's failures. You'll note that
they've all been
failing for
about a week.
== RED ==
Base: Failing tests since Mar 24
Forge: 2 test failures, 8 skipped tests since
Mar 24
Hibernate: COMPILATION FAILURES since ??? (last
good build on Feb 18)
JavaEE: 7 test failures since Mar 31; 11 test
failures since Mar 21
== YELLOW ==
Central: 1-2 test failures since Apr 1
JST: 20+ test failures since Mar 28
Web Services: 917 test failures since Mar 24