Hi Jan, you beat me to it by a couple of minutes (ok I could shave of some effort of debugging this by your analysis) by I was already looking down that road...
Regarding the solution... I see two different things here 1) A new dependency that blocks previously running tests (and maybe is fine in itself) 2) Tests (e.g. the groovy things) that suddenly need a UI to run (pretty sure this is not needed) While I think we should try to fix 1) we also should look into ensuring stuff that does not require a UI has no dependencies on UI. This would probably suggest moving some code out of the groovy.editor module, so that e.g. completion has its own module. I think similar things were already done to the Java support in the past. Comments? Ideas? Thanks again for your help Jan Sven On Thu, Apr 16, 2020 at 10:34 PM Jan Lahoda <lah...@gmail.com> wrote: > So, a little surprisingly (to me, at least), the issue is the new > dependency in options.editor, which now depends on core.windows. There are > various pieces of code on multiple places doing > WindowManager.invokeWhenUIReady. This method invokes the provided Runnable > when the UI is up and running. When running without WindowManager, this > maps to invokeLater(...), so the provided Runnable is ran at some point. > But the new dependency on core.windows brings in the full > WindowManager(Impl), which waits with these Runnables until the UI is > really ready. But it never is ready - there is never any UI actually shown! > And the tests are waiting for the effects of these Runnables to happen, but > they never do, leading to the failure. > > I could see various ways out of this, but one of the simplest: I think > options.editor only need the one new interface from core.windows, right? > Can we move the SPI interface to a less problematic module? (Frankly, not > sure if it really belongs to core.windows.) Maybe options.api? > > Jan > > On Thu, Apr 16, 2020 at 6:18 PM Laszlo Kishalmi <laszlo.kisha...@gmail.com > > > wrote: > > > Well, that's definitely strange. > > > > > > On 4/16/20 2:25 AM, Sven Reimers wrote: > > > Hi all, > > > > > > seems we have a couple of build failures in travis builds.. > > > > > > I only noticed in the process of my PR for latest groovy updates... > > > > > > Checking the failure against my local machine I figured out that the > > build > > > failures are also happening on my machine > > > > > > So I did a bit of git bisect and got this.. > > > > > > ab6a2ebc89b93c73dc89800efb18c42bcb6b3911 is the first bad commit > > > commit ab6a2ebc89b93c73dc89800efb18c42bcb6b3911 > > > Author: Laszlo Kishalmi <laszlo.kisha...@gmail.com> > > > Date: Fri Mar 20 07:34:47 2020 -0700 > > > > > > [NETBEANS-4039] Added SPI for Preferred Color Profile Changes > > > > > > ide/options.editor/nbproject/project.xml | 9 +++ > > > .../modules/options/colors/ColorModel.java | 19 +++++- > > > platform/core.windows/apichanges.xml | 20 +++++++ > > > platform/core.windows/manifest.mf | 2 +- > > > platform/core.windows/nbproject/project.xml | 7 +-- > > > .../netbeans/core/windows/options/LafPanel.java | 70 > > > ++++++---------------- > > > .../options/spi/PreferredColorProfileSupport.java | 50 > > ++++++++++++++++ > > > 7 files changed, 117 insertions(+), 60 deletions(-) > > > create mode 100644 > > > > > > platform/core.windows/src/org/netbeans/core/windows/options/spi/PreferredColorProfileSupport.java > > > > > > The test I was running is > > > > > > ant -f "/Users/sven/work/netbeans/nbgroovy2.5.11/groovy/groovy.editor" > > > "-Dtest.type=unit" "-Dcontinue.after.failing.tests=true" > > > > > > "-Dtest.includes=org/netbeans/modules/groovy/editor/api/**/AstPathTest.java" > > > test-single > > > > > > which is timing out on travis and on my machine as well.. > > > > > > Based on this I triggered two travis runs > > > > > > Still good > > > https://travis-ci.org/github/apache/netbeans/builds/672968563 > > > > > > First bad > > > https://travis-ci.org/github/apache/netbeans/builds/672968787 > > > > > > So this seems to support my first local analysis that the merge seems > to > > > introduce the problem. > > > > > > I have no clue at the moment how this is related (would have never > > guessed > > > the change is causing the disruption), but will try to dig deeper so we > > get > > > green builds on travis again.. > > > > > > I think we should ensure a green travis (at least on the 12.0 branch) > > > before considering releasing. > > > > > > Any ideas? Suggestions where to look further? > > > > > > Thanks for listening > > > > > > Sven > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@netbeans.apache.org > > For additional commands, e-mail: dev-h...@netbeans.apache.org > > > > For further information about the NetBeans mailing lists, visit: > > https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists > > > > > > > > > -- Sven Reimers * Java Champion * Apache NetBeans PMC: http://netbeans.apache.org * JUG Leader JUG Bodensee: https://www.meetup.com/JUG-Bodensee * Duke's Choice Award Winner 2009 & 2018 * LinkedIn: http://www.linkedin.com/in/svenreimers
