> 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