On Thu, Apr 16, 2020 at 11:01 PM Sven Reimers <sven.reim...@gmail.com> wrote:
> 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? > If you want to separate e.g. completion from groovy.editor, sure, why not. But note that in this case, I think it was probably invokeWhenUIReady in org.netbeans.modules.project.ui.OpenProjectList$2.run(OpenProjectList.java:206) that triggered the "deadlock", so it does not have much do to with groovy editor as such. Jan > 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 >
