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-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
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
