> 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