Re: Build Failures on Travis

Hi all, I created a PR https://github.com/apache/netbeans/pull/2085 to enable Travis cache https://docs.travis-ci.com/user/caching/ It tries to prevent network issues like OSUOSL failures, etc. Hector El sáb., 18 abr. 2020 a las 16:44, Laszlo Kishalmi (< laszlo.kisha...@gmail.com>) escribió: >

Re: Build Failures on Travis

I've created a revert PR: https://github.com/apache/netbeans/pull/2088 Approve and merge, please! On 4/18/20 1:36 AM, Jan Lahoda wrote: Hi Laszlo, On Thu, Apr 16, 2020 at 11:09 PM Laszlo Kishalmi wrote: Let's just remove that commit from the code, at least from now. Will you do that, or

Re: Build Failures on Travis

Hi Laszlo, On Thu, Apr 16, 2020 at 11:09 PM Laszlo Kishalmi wrote: > Let's just remove that commit from the code, at least from now. > Will you do that, or do you want me to do it? Thanks, Jan > The reflection hack that it would have replaced works. > > On 4/16/20 1:34 PM, Jan Lahoda wro

Re: Build Failures on Travis

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 b

Re: Build Failures on Travis

On Thu, Apr 16, 2020 at 11:01 PM Sven Reimers 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)

Re: Build Failures on Travis

Let's just remove that commit from the code, at least from now. The reflection hack that it would have replaced works. On 4/16/20 1:34 PM, Jan Lahoda 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 a

Re: Build Failures on Travis

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

Re: Build Failures on Travis

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

Re: Build Failures on Travis

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

Re: Build Failures on Travis

On Thu, 16 Apr 2020 at 10:25, Sven Reimers wrote: > I think we should ensure a green travis (at least on the 12.0 branch) > before considering releasing. +1, and I'd go further than that. Nothing should be merged to master unless Travis has gone green (eventually!), particularly within the relea

Build Failures on Travis

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.