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
