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 <mbie...@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-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 > > > > -- Eric Bresie ebre...@gmail.com
