Hi Jan, I would have guessed, that separating stuff like completion, which should not be dependent on the UI, out of modules which have a "tendency" to be UI bound, would be good for stability of tests.
If we introduce new dependencies towards UI stuff we should be just more aware that we cross borders, which may be more visible if we separate stuff on a module level.. Thanks for your feedback Sven On Fri, Apr 17, 2020 at 7:49 AM Jan Lahoda <lah...@gmail.com> wrote: > 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 > > > -- 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
