You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Laszlo Kishalmi <la...@gmail.com> on 2022/08/01 01:11:03 UTC
Re: java/gradle.java tests
Just keep debugging the issue. It seems it is file system dependent.
The testcase does a a trick to simulate open -> load -> close -> check
without open, by doing some file system operations, copying the project
over, then rename it back to the same location.
In some cases it makes the timestamps of the build files modified. With
that, it makes the disk cache invalid. And right now invalid disk cache
is discarded.
What can be done is to return the invalid cache data as EVALUATED.
Also later on the data validation could be based on the content of build
files instead of timestamps, though that might be an overkill just for
this non-usual use case.
On 7/31/22 03:36, Michael Bien wrote:
> Thanks for looking into this Laszlo,
>
> so you think it is a coincidence that it is working when run by travis
> but nowhere else?
>
> can I mark this test method with @RandomlyFails for now?
>
> I suppose we could also leave this test on travis for now. What I
> tried to do is to aggregate all "build tool" IDE features into one CI
> job which is only run if the PR is labeled with Ant, Gradle, Maven,
> (...).
>
> https://github.com/apache/netbeans/pull/4431
>
> the idea is to let devs/reviewers decide what has to be tested before
> integration, based on what is actually influenced by the PR so that CI
> can skip some long jobs (short ones are tested since that won't make a
> difference anyway resource wise).
> https://github.com/apache/netbeans/pull/4431
>
> best regards,
> michael
>
>
> On 31.07.22 03:49, Laszlo Kishalmi wrote:
>> It seem I have my own history with that test.
>>
>> See: https://github.com/apache/netbeans/pull/3298
>>
>> The discussion in the PR mostly on the first disabled testcase, as
>> the ScriptEngine it was not correctly initialized on Java 11. That
>> got solved.
>>
>> The other TC I put on the Ignore list is a wish to be working case of
>> Gradle project loading infrastructure. I do not know if Svata managet
>> to get that work in a branch or not, but I have not seen it working.
>>
>>
>> Some background info:
>>
>> NetBeans Gradle projects tracks the quality of information it is
>> having on the actual Gradle project. Information is like classparhs,
>> dependencies, etc.
>>
>> There are 3 main qualities (the actual implementation is more
>> granular though):
>>
>> FALLBACK - The information is guessed by heuristics, Gradle was not
>> asked to fetch it.
>>
>> FULL - Gradle returned the full information, NetBeans shall know
>> everything it needs.
>>
>> EVALUATED - We turned to Gradle at least once, but the last attempt
>> had issues, so we shall live with the last information we have, but
>> shall try to retrieve the FULL information whenever we have the chance.
>>
>> So when NetBeans sees a Gradle project, for performance reasons it
>> loads the FALLBACK information using heuristics.
>>
>> However imagine the situation, that once upon a time we have opened a
>> project, and that got inspected by Gradle, so NetBeans has the
>> project information in disk cache.
>>
>> Now we close the project, maybe NetBeans as well.
>>
>> Next time you have a project open, which uses some classes from an
>> un-opened Gradle project. Just clicking on the Go to source, should
>> gisplay the file from the closed project, but it is marked all read,
>> as the project just have the FALLBACK information on the classpath.
>>
>> However in that case we have the project information easily
>> accessible in the disk cache, which if valid could hold the FULL
>> information, even with invalid cache loading that info (EVALUATED)
>> could be better than the heuristic. (There are other use cases where
>> this would be useful as well)
>>
>> That is the behavior this failing TestCase is for. Unfortunately
>> right now the Gradle plugin does not work that way.
>>
>>
>> On 7/30/22 04:28, Michael Bien wrote:
>>> Hi,
>>>
>>> I am having trouble to get those tests green while working on moving
>>> more jobs from travis to github. They appear to work "ok" on travis
>>> but fail both locally and on github.
>>>
>>> Since the tests are marked unreliable (exile job) with a retry
>>> command, I would like to exclude that I am just hitting some weird
>>> timing issue here with tests which only work on travis when all
>>> stars align.
>>>
>>> Do they work for anyone locally?
>>>
>>> Travis runs them with this line on JDK 8:
>>>
>>> OPTS="-Dmetabuild.jsonurl=https://raw.githubusercontent.com/apache/netbeans-jenkins-lib/master/meta/netbeansrelease.json
>>> -Dcluster.config=java -Djavac.compilerargs=-nowarn
>>> -Dbuild.compiler.deprecation=false
>>> -Dtest-unit-sys-prop.ignore.random.failures=true"
>>>
>>> ant $OPTS -f java/gradle.java test
>>>
>>> ClassPathProviderImplTest.testCompilePreTrusted is failing my my
>>> case. It fails the exact same way when simply started from NetBeans,
>>> in a shell or on github. The log has lots of exceptions and "can't
>>> load module" warnings, but I went so far to diff the travis log
>>> (without -quiet) with the local log and they exist in both cases at
>>> the same places.
>>>
>>> best regards,
>>>
>>> michael
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>>
>>> For further information about the NetBeans mailing lists, visit:
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>
>> For further information about the NetBeans mailing lists, visit:
>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
Re: java/gradle.java tests
Posted by Laszlo Kishalmi <la...@gmail.com>.
Proposed fix: https://github.com/apache/netbeans/pull/4456
On 7/31/22 18:11, Laszlo Kishalmi wrote:
> Just keep debugging the issue. It seems it is file system dependent.
>
> The testcase does a a trick to simulate open -> load -> close -> check
> without open, by doing some file system operations, copying the
> project over, then rename it back to the same location.
>
> In some cases it makes the timestamps of the build files modified.
> With that, it makes the disk cache invalid. And right now invalid disk
> cache is discarded.
>
> What can be done is to return the invalid cache data as EVALUATED.
>
> Also later on the data validation could be based on the content of
> build files instead of timestamps, though that might be an overkill
> just for this non-usual use case.
>
>
> On 7/31/22 03:36, Michael Bien wrote:
>> Thanks for looking into this Laszlo,
>>
>> so you think it is a coincidence that it is working when run by
>> travis but nowhere else?
>>
>> can I mark this test method with @RandomlyFails for now?
>>
>> I suppose we could also leave this test on travis for now. What I
>> tried to do is to aggregate all "build tool" IDE features into one CI
>> job which is only run if the PR is labeled with Ant, Gradle, Maven,
>> (...).
>>
>> https://github.com/apache/netbeans/pull/4431
>>
>> the idea is to let devs/reviewers decide what has to be tested before
>> integration, based on what is actually influenced by the PR so that
>> CI can skip some long jobs (short ones are tested since that won't
>> make a difference anyway resource wise).
>> https://github.com/apache/netbeans/pull/4431
>>
>> best regards,
>> michael
>>
>>
>> On 31.07.22 03:49, Laszlo Kishalmi wrote:
>>> It seem I have my own history with that test.
>>>
>>> See: https://github.com/apache/netbeans/pull/3298
>>>
>>> The discussion in the PR mostly on the first disabled testcase, as
>>> the ScriptEngine it was not correctly initialized on Java 11. That
>>> got solved.
>>>
>>> The other TC I put on the Ignore list is a wish to be working case
>>> of Gradle project loading infrastructure. I do not know if Svata
>>> managet to get that work in a branch or not, but I have not seen it
>>> working.
>>>
>>>
>>> Some background info:
>>>
>>> NetBeans Gradle projects tracks the quality of information it is
>>> having on the actual Gradle project. Information is like classparhs,
>>> dependencies, etc.
>>>
>>> There are 3 main qualities (the actual implementation is more
>>> granular though):
>>>
>>> FALLBACK - The information is guessed by heuristics, Gradle was not
>>> asked to fetch it.
>>>
>>> FULL - Gradle returned the full information, NetBeans shall know
>>> everything it needs.
>>>
>>> EVALUATED - We turned to Gradle at least once, but the last attempt
>>> had issues, so we shall live with the last information we have, but
>>> shall try to retrieve the FULL information whenever we have the chance.
>>>
>>> So when NetBeans sees a Gradle project, for performance reasons it
>>> loads the FALLBACK information using heuristics.
>>>
>>> However imagine the situation, that once upon a time we have opened
>>> a project, and that got inspected by Gradle, so NetBeans has the
>>> project information in disk cache.
>>>
>>> Now we close the project, maybe NetBeans as well.
>>>
>>> Next time you have a project open, which uses some classes from an
>>> un-opened Gradle project. Just clicking on the Go to source, should
>>> gisplay the file from the closed project, but it is marked all read,
>>> as the project just have the FALLBACK information on the classpath.
>>>
>>> However in that case we have the project information easily
>>> accessible in the disk cache, which if valid could hold the FULL
>>> information, even with invalid cache loading that info (EVALUATED)
>>> could be better than the heuristic. (There are other use cases where
>>> this would be useful as well)
>>>
>>> That is the behavior this failing TestCase is for. Unfortunately
>>> right now the Gradle plugin does not work that way.
>>>
>>>
>>> On 7/30/22 04:28, Michael Bien wrote:
>>>> Hi,
>>>>
>>>> I am having trouble to get those tests green while working on
>>>> moving more jobs from travis to github. They appear to work "ok" on
>>>> travis but fail both locally and on github.
>>>>
>>>> Since the tests are marked unreliable (exile job) with a retry
>>>> command, I would like to exclude that I am just hitting some weird
>>>> timing issue here with tests which only work on travis when all
>>>> stars align.
>>>>
>>>> Do they work for anyone locally?
>>>>
>>>> Travis runs them with this line on JDK 8:
>>>>
>>>> OPTS="-Dmetabuild.jsonurl=https://raw.githubusercontent.com/apache/netbeans-jenkins-lib/master/meta/netbeansrelease.json
>>>> -Dcluster.config=java -Djavac.compilerargs=-nowarn
>>>> -Dbuild.compiler.deprecation=false
>>>> -Dtest-unit-sys-prop.ignore.random.failures=true"
>>>>
>>>> ant $OPTS -f java/gradle.java test
>>>>
>>>> ClassPathProviderImplTest.testCompilePreTrusted is failing my my
>>>> case. It fails the exact same way when simply started from
>>>> NetBeans, in a shell or on github. The log has lots of exceptions
>>>> and "can't load module" warnings, but I went so far to diff the
>>>> travis log (without -quiet) with the local log and they exist in
>>>> both cases at the same places.
>>>>
>>>> best regards,
>>>>
>>>> michael
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>>>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>>>
>>>> For further information about the NetBeans mailing lists, visit:
>>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>>
>>>>
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
>>> For additional commands, e-mail: dev-help@netbeans.apache.org
>>>
>>> For further information about the NetBeans mailing lists, visit:
>>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
>>>
>>>
>>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@netbeans.apache.org
For additional commands, e-mail: dev-help@netbeans.apache.org
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists