You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@netbeans.apache.org by Michael Bien <mb...@gmail.com> on 2022/07/30 11:28:18 UTC
java/gradle.java tests
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
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
Re: java/gradle.java tests
Posted by Laszlo Kishalmi <la...@gmail.com>.
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 Eric Bresie <eb...@gmail.com>.
Is this related to problems discussed previously (1),(2),(3),(4)?
I think if I remember correctly Gradle initiates a daemon to speed things
up which may have some conflicting Java versions involved or the daemon may
lock some files
(1) https://lists.apache.org/thread/262qq315n7zy9pz9d2849x1wrb6nrrgd
(2) https://lists.apache.org/thread/rx46cgwy0t44z0dyw5ylb524djj9g20c
(3) https://lists.apache.org/thread/76jwd8ov418chnkxy2x0k7819qgxqstj
(4) https://lists.apache.org/thread/5nd3kbr53qql0dopxcyg2h40dskfcnn2
On Sun, Jul 31, 2022 at 5:39 AM Michael Bien <mb...@gmail.com> 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
>
>
>
> --
Eric Bresie
ebresie@gmail.com
Re: java/gradle.java tests
Posted by Michael Bien <mb...@gmail.com>.
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>.
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