Fix spurious messages printed to the console.

[sdedic]

During testing of NB17, I've seen some messages printed to the console that should not be there.

1/ Maven creates a fallback project, if the pom.xml cannot be read into the model. This is a fairly common, either because of malformed XML, inaccessible basic build plugin (i.e. empty repository) etc. Should be logged, but not at INFO level - that is likely a leftover after debugging maven actions.

Reload broken project (clean repository): diagnostic message
INFO [org.netbeans.modules.maven.modelcache.MavenProjectCache]: Creating fallback project for /space/tmp/vsc2/src/microtest/pom.xml
java.lang.Throwable
        at org.netbeans.modules.maven.modelcache.MavenProjectCache.getFallbackProject(MavenProjectCache.java:358)
        at org.netbeans.modules.maven.modelcache.MavenProjectCache.loadOriginalMavenProject(MavenProjectCache.java:332)
        at org.netbeans.modules.maven.modelcache.MavenProjectCache.loadOriginalMavenProject(MavenProjectCache.java:157)
        at org.netbeans.modules.maven.modelcache.MavenProjectCache.access$200(MavenProjectCache.java:64)

2/ After a clean startup with Ergonomics, when Java SE feature is activated, a stacktrace prints to the console from unsuccessful JShell console deserialization:

Class: class org.netbeans.modules.jshell.editor.ConsoleEditor
Source: MultiFileObject@7a679502[Windows2Local/Components/JShellEditor.settings]
Caused: java.lang.NoSuchMethodException: org.netbeans.modules.jshell.editor.ConsoleEditor.<init>()
        at java.base/java.lang.Class.getConstructor0(Class.java:3349)
        at java.base/java.lang.Class.getDeclaredConstructor(Class.java:2553)
        at org.netbeans.modules.settings.convertors.XMLSettingsSupport.newInstance(XMLSettingsSupport.java:73)
        at org.netbeans.modules.settings.convertors.XMLSettingsSupport$SettingsRecognizer.instanceCreate(XMLSettingsSupport.java:603)

The window is marked as PERSISTENCE_NEVER but the .settings file is there because of @TopComponent.Registration. Other similar windows use a default constructor with limited initialization and features - this patch addds the same.

[mbien]

nice! thanks for investigating the jshell bug! (restarted the enterprise job since micronaut failed)

[mbien]

tests keep failing after 4 restarts, but that is caused by #5507 most likely

[sdedic]

tests keep failing after 4 restarts, but that is caused by #5507 most likely

I doubt that 5507 is involved, as that one only changes package.json in vscode ext that cannot participate in java micronaut tests (the ones that are failing) in any way.

[mbien]

tests keep failing after 4 restarts, but that is caused by #5507 most likely

I doubt that 5507 is involved, as that one only changes package.json in vscode ext that cannot participate in java micronaut tests (the ones that are failing) in any way.

could be only a coincidence of course and it might be something entirely different but a few things indicate that it might be the PR above, since everything started after it was merged - restarting doesn't help.

[sdedic]

From the logs I see the tests run against

2023-02-20T09:27:59.7510472Z  * [new ref]             c02d66d5a6b20bd5383f2fe949b585f14d710bf2 -> pull/5538/merge

so I'll try to run tests on that exact commit locally. We'll see. There is some burried race condition with project infrastructure that causes micronaut and/or maven project tests to fail occasionally.

If that does not help, I'll add some debugging / logging to this PR as an attempt to catch the issue.

[mbien]

i diffed the log of the last green run on master and the first failing run on master and noticed something interesting:
the stack trace changes slightly, compare:

• https://github.com/apache/netbeans/actions/runs/4213555133/jobs/7313435246#step:6:972 with
• https://github.com/apache/netbeans/actions/runs/4222367720/jobs/7333205049#step:6:979

also note that the test method is different which means that the exception occurs at a different time in the same test.

edit: looks like the tests are ran in a different order?

[sdedic]

Marvellous ... when I run the test locally, it failed += same way on an empty gradle repository (with my usual repo content, download was not necessary). Then I run that from commandline (gradle build) and:

> Configure project :oci
[native-image-plugin] Instrumenting task with the native-image-agent: test
[native-image-plugin] Instrumenting task with the native-image-agent: testNativeImage

FAILURE: Build failed with an exception.

   > Could not resolve io.micronaut:micronaut-bom:3.7.0-SNAPSHOT.
     Required by:
         project :oci
         project :oci > project :app
      > Could not resolve io.micronaut:micronaut-bom:3.7.0-SNAPSHOT.
         > Unable to load Maven meta-data from https://s01.oss.sonatype.org/content/repositories/snapshots/io/micronaut/micronaut-bom/3.7.0-SNAPSHOT/maven-metadata.xml.
            > Could not GET 'https://s01.oss.sonatype.org/content/repositories/snapshots/io/micronaut/micronaut-bom/3.7.0-SNAPSHOT/maven-metadata.xml'.
               > Read timed out

I LOVE cloud solutions and repositories...

[neilcsmith-net]

I LOVE cloud solutions and repositories...

... especially when they rely on SNAPSHOTs! 😄

[mbien]

we should consider to put things like this into the cache (I suppose it lands in the global .m2 folder?). Unfortunately jobs like graalvm download so much that it wouldn't fit since we only have 10gb in total. Currently only the build jobs use the cache.

[sdedic]

Hm, I think it's actually good that the tests run from a pristine repository: it's hard to spot this kind of bug on a dev machine with all the artifacts and their whatever versions downloaded during development.

[mbien]

Hm, I think it's actually good that the tests run from a pristine repository: it's hard to spot this kind of bug on a dev machine with all the artifacts and their whatever versions downloaded during development.

its a question how well we pick the cache key. The build jobs hash all binaries-list files, which works really well so far:
https://github.com/apache/netbeans/blob/master/.github/workflows/main.yml#L114

gradle cache config could look like this:
https://github.com/actions/cache/blob/main/examples.md#java---gradle

the graalvm cache key could be the graalvm git tag (but I fear the whole jdk repo is too big to put into the cache)

[mbien]

all green - thanks a lot for fixing everything :)

[neilcsmith-net]

Hm, I think it's actually good that the tests run from a pristine repository

That makes some sense. Certainly the reason we bypass the local .m2 folder in the build #2710 was due to corruption of the local repository on the Jenkins nodes.

I do think that having any test, or anything in the build, relying on a remote -SNAPSHOT is asking for trouble. And non-snapshot availability should be much better anyway?!

[mbien]

@neilcsmith-net i was more thinking about things which aren't downloaded by DownloadBinaries.java.

the PR you linked is actually super important since it makes sure everything lands in .hgexternalcache which is later cached by CI using the hashes of binaries-list as key. If part of it would be loaded from .m2 it would be unpredictable what lands in the build cache and what will be redownloaded again.