Should probably mention too that if you're not seeing these failures locally, you should look to the console logs to see how Jenkins is running your jobs's builds and tests. For example, looking at the Base build from master branch (jbosstools-base_master) I see these two calls to mvn in the log [1]:

[jbosstools-base_master] $ /qa/tools/opt/apache-maven-3.0.4/bin/mvn -f /qa/services/hudson/hudson_workspace/workspace/jbosstools-base_master/sources/pom.xml -DTARGET_PLATFORM_VERSION=4.30.5.Alpha3-SNAPSHOT -DTARGET_PLATFORM_VERSION_MAXIMUM=4.30.5.Alpha3-SNAPSHOT -DDISPLAY=:1 "-DMAVEN_FLAGS=-B -U -fae -e -P hudson,pack200,jbosstools-nightly-staging-composite,unified.target" -DskipRevisionCheckWhenPublishing=false -Ddownload.cache.directory=/home/hudson/static_build_env/jbds/download-cache -Dmaven.test.skip=true -DBUILD_ID=2013-04-02_16-57-03 -DJOB_NAME=jbosstools-base_master -DskipPrivateRequirements=false -DBUILD_NUMBER=215 -Dmaven.repo.local=/qa/services/hudson/hudson_workspace/workspace/jbosstools-base_master/.repository clean install -B -U -fae -e -P hudson,pack200,jbosstools-nightly-staging-composite,unified.target -gs /home/hudson/.m2/settings.xml -s /qa/services/hudson/hudson_workspace/workspace/jbosstools-base_master/settings/hudson-settings.xml -DTARGET_PLATFORM_VERSION=4.30.5.Alpha3-SNAPSHOT and [jbosstools-base_master] $ /qa/tools/opt/apache-maven-3.0.4/bin/mvn -f /qa/services/hudson/hudson_workspace/workspace/jbosstools-base_master/sources/all-tests/pom.xml -DTARGET_PLATFORM_VERSION=4.30.5.Alpha3-SNAPSHOT -DTARGET_PLATFORM_VERSION_MAXIMUM=4.30.5.Alpha3-SNAPSHOT -DDISPLAY=:1 "-DMAVEN_FLAGS=-B -U -fae -e -P hudson,pack200,jbosstools-nightly-staging-composite,unified.target" -DskipRevisionCheckWhenPublishing=false -Ddownload.cache.directory=/home/hudson/static_build_env/jbds/download-cache -Dmaven.test.failure.ignore=true -Dmaven.test.error.ignore=true -DBUILD_ID=2013-04-02_16-57-03 -DJOB_NAME=jbosstools-base_master -DskipPrivateRequirements=false -DBUILD_NUMBER=215 -Dmaven.repo.local=/qa/services/hudson/hudson_workspace/workspace/jbosstools-base_master/.repository verify -B -U -fae -e -P hudson,pack200,jbosstools-nightly-staging-composite,unified.target -gs /home/hudson/.m2/settings.xml -s /qa/services/hudson/hudson_workspace/workspace/jbosstools-base_master/settings/hudson-settings.xml -DTARGET_PLATFORM_VERSION=4.30.5.Alpha3-SNAPSHOT [1] https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... You don't need to worry about JOB_NAME, BUILD_ID, and BUILD_NUMBER, but the rest of the commandline arguments are useful. Using settings.xml is not required either: it only allows Jenkins to build against local mirrors of content otherwise located on download.jboss.org/jbosstools/ On 04/03/2013 12: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 > -- Nick Boldt :: JBoss by Red Hat Productization Lead :: JBoss Tools & Dev Studio http://nick.divbyzero.com _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On Wed, Apr 03, 2013 at 02:34:32PM -0400, Nick Boldt wrote: > Should probably mention too that if you're not seeing these failures > locally, you should look to the console logs to see how Jenkins is > running your jobs's builds and tests. > > For example, looking at the Base build from master branch > (jbosstools-base_master) I see these two calls to mvn in the log [1]: These multiline flags doesn't help much since they are *very* jenkins specific. the important part is the TARGET_PLATFORM_VERSION, the rest should not affect us - if it does we got bigger problems. /max > [jbosstools-base_master] $ /qa/tools/opt/apache-maven-3.0.4/bin/mvn -f > /qa/services/hudson/hudson_workspace/workspace/jbosstools-base_master/sources/pom.xml > > -DTARGET_PLATFORM_VERSION=4.30.5.Alpha3-SNAPSHOT > -DTARGET_PLATFORM_VERSION_MAXIMUM=4.30.5.Alpha3-SNAPSHOT -DDISPLAY=:1 > "-DMAVEN_FLAGS=-B -U -fae -e -P > hudson,pack200,jbosstools-nightly-staging-composite,unified.target" > -DskipRevisionCheckWhenPublishing=false > -Ddownload.cache.directory=/home/hudson/static_build_env/jbds/download-cache > > -Dmaven.test.skip=true -DBUILD_ID=2013-04-02_16-57-03 > -DJOB_NAME=jbosstools-base_master -DskipPrivateRequirements=false > -DBUILD_NUMBER=215 > -Dmaven.repo.local=/qa/services/hudson/hudson_workspace/workspace/jbosstools-base_master/.repository > > clean install -B -U -fae -e -P > hudson,pack200,jbosstools-nightly-staging-composite,unified.target -gs > /home/hudson/.m2/settings.xml -s > /qa/services/hudson/hudson_workspace/workspace/jbosstools-base_master/settings/hudson-settings.xml > > -DTARGET_PLATFORM_VERSION=4.30.5.Alpha3-SNAPSHOT > > and > > [jbosstools-base_master] $ /qa/tools/opt/apache-maven-3.0.4/bin/mvn -f > /qa/services/hudson/hudson_workspace/workspace/jbosstools-base_master/sources/all-tests/pom.xml > > -DTARGET_PLATFORM_VERSION=4.30.5.Alpha3-SNAPSHOT > -DTARGET_PLATFORM_VERSION_MAXIMUM=4.30.5.Alpha3-SNAPSHOT -DDISPLAY=:1 > "-DMAVEN_FLAGS=-B -U -fae -e -P > hudson,pack200,jbosstools-nightly-staging-composite,unified.target" > -DskipRevisionCheckWhenPublishing=false > -Ddownload.cache.directory=/home/hudson/static_build_env/jbds/download-cache > > -Dmaven.test.failure.ignore=true -Dmaven.test.error.ignore=true > -DBUILD_ID=2013-04-02_16-57-03 -DJOB_NAME=jbosstools-base_master > -DskipPrivateRequirements=false -DBUILD_NUMBER=215 > -Dmaven.repo.local=/qa/services/hudson/hudson_workspace/workspace/jbosstools-base_master/.repository > > verify -B -U -fae -e -P > hudson,pack200,jbosstools-nightly-staging-composite,unified.target -gs > /home/hudson/.m2/settings.xml -s > /qa/services/hudson/hudson_workspace/workspace/jbosstools-base_master/settings/hudson-settings.xml > > -DTARGET_PLATFORM_VERSION=4.30.5.Alpha3-SNAPSHOT > > [1] > https://jenkins.mw.lab.eng.bos.redhat.com/hudson/view/DevStudio/view/DevS... > > > You don't need to worry about JOB_NAME, BUILD_ID, and BUILD_NUMBER, but > the rest of the commandline arguments are useful. Using settings.xml is > not required either: it only allows Jenkins to build against local > mirrors of content otherwise located on download.jboss.org/jbosstools/ > > On 04/03/2013 12: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 >> > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On Wed, Apr 03, 2013 at 12:30:23PM -0400, Nick Boldt wrote: > Hibernate: COMPILATION FAILURES since ??? (last good build on Feb 18) This is happening because the build is set to use Alpha3 which contains M6. Denis got a PR https://github.com/jbosstools/jbosstools-hibernate/pull/13 which I'll need to look at with Koen on PTO. Added to my todo list. p.s. post links to the builds - much easier than hunting down ;) > 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 > > -- > Nick Boldt :: JBoss by Red Hat > Productization Lead :: JBoss Tools & Dev Studio > http://nick.divbyzero.com > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

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 >

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/JBo... > > > > 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 >>> >> >

Isn't there a commandline flag to suppress that so that the test DOES NOT block until timeout? 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/JBo... >>> >>> >>> >>> 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 >>>>>

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/JBo... >>>> >>>> >>>> >>>> >>>> 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 >>>>>>

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.

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/JBo... >>>>> >>>>> >>>>> >>>>> >>>>> 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 >>>>>>> >

> 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/JBo... >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> 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 >>>>>>>>> >>> >> >

On Fri, Apr 05, 2013 at 10:08:03PM +0200, 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. > > 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. hmm - what is that change ? Is it affecting how startup extension points are run or how tests are run together ? Seems like a subtle surprising change ...curious what it is and if it was intended to happen. Any idea ?

You may want to take a look at https://github.com/jbosstools/jbosstools-base/pull/77

Snjeza On 4/6/2013 3:31 PM, Snjezana Peco wrote: > On 4/6/2013 4:12 AM, Max Rydahl Andersen wrote: >> On Fri, Apr 05, 2013 at 10:08:03PM +0200, 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. >>> >>> 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. >> hmm - what is that change ? >> >> Is it affecting how startup extension points are run or how tests are >> run together ? >> >> Seems like a subtle surprising change ...curious what it is and if it >> was intended to happen. >> >> Any idea ? >> > The way the E4 UISynchronizer runs UI messages seems to be changed. > > The usage tests run in the following way: > > - the usage_reporting_enabled property is set to false in the parent pom > - Eclipse starts the usage extension point that triggers opening the > dialog asynchronously > - Eclipse runs tests that set the usage_reporting_enabled property to > true > > Eclipse < Kepler M6 works as follows: > > - the usage_reporting_enabled property is set to false in the parent pom > - Eclipse starts the usage extension point that triggers opening the > dialog asynchronously > - Eclipse tries to open the dialog; since usage_reporting_enabled=false, > the dialog isn't open > - Eclipse runs tests that set the usage_reporting_enabled property to > true > > Kepler M6 on Linux works in the following way: > > - the usage_reporting_enabled property is set to false in the parent pom > - Eclipse starts the usage extension point that triggers opening the > dialog asynchronously > - Eclipse runs tests that set the usage_reporting_enabled property to > true > - Eclipse tries to open the dialog; since usage_reporting_enabled=true, > the dialog is open > > There are no more Eclipse instances when running a test plugin. > Also, it is not important if a test is an UI test or not. Eclipse will > always call the usage's startup ext. point if the usage plugin is > included which will trigger opening the dialog. > > You can check this as follows: > - clone the jbosstools-build component > - remove -Dusage_reporting_enabled=false from the parent/pom.xml > - mvn clean install -f parent/pom.xml > - cd <usage_test_directory> > - mvn clean verify > The test will always freeze - on Linux, Windows, Mac, Kepler M6, Kepler > M5, Indigo... > > Snjeza > > _______________________________________________ > jbosstools-dev mailing list > jbosstools-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosstools-dev

> The way the E4 UISynchronizer runs UI messages seems to be changed. > > The usage tests run in the following way: > > - the usage_reporting_enabled property is set to false in the parent pom > - Eclipse starts the usage extension point that triggers opening the > dialog asynchronously > - Eclipse runs tests that set the usage_reporting_enabled property to > true > > Eclipse < Kepler M6 works as follows: > > - the usage_reporting_enabled property is set to false in the parent pom > - Eclipse starts the usage extension point that triggers opening the > dialog asynchronously > - Eclipse tries to open the dialog; since > usage_reporting_enabled=false, the dialog isn't open > - Eclipse runs tests that set the usage_reporting_enabled property to > true > > Kepler M6 on Linux works in the following way: > > - the usage_reporting_enabled property is set to false in the parent pom > - Eclipse starts the usage extension point that triggers opening the > dialog asynchronously > - Eclipse runs tests that set the usage_reporting_enabled property to > true > - Eclipse tries to open the dialog; since > usage_reporting_enabled=true, the dialog is open > so to sum up >= Kepler M6, the tests are run before the Eclipse extension tries to open the dialog, right (< Kepler M6 it's the other way round)?

I have no idea whether this is expected or not. Who does actually decide? > There are no more Eclipse instances when running a test plugin. I dont get this one, can you please explain more?

> Also, it is not important if a test is an UI test or not. Eclipse will > always call the usage's startup ext. point if the usage plugin is > included which will trigger opening the dialog. Sure, no doubt.

> You can check this as follows: > - clone the jbosstools-build component > - remove -Dusage_reporting_enabled=false from the parent/pom.xml > - mvn clean install -f parent/pom.xml > - cd <usage_test_directory> > - mvn clean verify > The test will always freeze - on Linux, Windows, Mac, Kepler M6, > Kepler M5, Indigo... > > Snjeza > _______________________________________________ jbosstools-dev mailing list jbosstools-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosstools-dev

On Wed, Apr 10, 2013 at 02:52:53PM +0200, Snjezana Peco wrote: > No. The startup extension points are always run first. Kepler M6 UI > Synchronizer has been changed. > See Workbench.java i'm interested in this - got a github or code link ? :)

This extension point is used to register plugins that want to be

...