disable compile-on-save by default in maven projects.

[mbien]

"good defaults" round two, see dev list or #5260

sets CoS default to none

some reasons why:

• CoS is an intrusive feature which sidelines the build and compiles directly into the target folder (using javac from the NB runtime)
• UX wise this asks for being an opt-in feature, enabling it via the checkbox will even display an info dialog stating the risks, a dialog users would never see when it is enabled by default
• mvnd and other incremental improvements make CoS less interesting

[lkishalmi]

Thanks. It's a good thing to do.

Later on we probably should think about removing this feature. It was a big time-saver 10 years ago, but it is a can of worms now. Unfortunately this has more tentacles in the enterprise cluster as well.

I remember when I tried to implement this feature for Gradle, even had a semi-working branch as well, but couldn't get it right. Then Gradle continuous build option came out and the whole thing got obsolete.

[morvael]

With this change I have lost the ability to work with myBatis result maps in test classes. I had to turn compile on save manually on. org.apache.ibatis.io.ResolverUtil fails to detect classes properly if referenced projects go to classpath as their jars in repository vs target/classes directory (which is the result of compile on save option change). Please, never remove that option.

[neilcsmith-net]

@morvael you have more of an issue if your tests rely on having compile on save enabled! I would look at what's required to have them work correctly without it.

[morvael]

MyBatis loads result map files from xml file in project's resources when loading its configuration. That file tells it about some aliased classes. And then it gets ClassNotFoundException for such class, because the ResolverUtil has not found it somehow. I checked run class command difference and classpath difference for the same code run in NB 17 vs NB 18 and the differences are:

1. process-test-classes is added to exec plugin command line
2. projects that are referenced in class path that have compile on save disabled change from someproject/target/classes to ./m2/repository/.../someproject-someversion.jar

And it is the second change that somehow prevents the MyBatis code from scanning them correctly and finding annotated classes. The same problem does not happen when the application is actually deployed on application server. It's only a problem inside IDE when trying to "Run" a class with main method.

[morvael]

[org.apache.ibatis.io.VFS] [main] [DEBUG] [org.apache.ibatis.io.VFS$VFSHolder] [createVFS] [74] : Using VFS adapter org.apache.ibatis.io.JBoss6VFS
[org.apache.ibatis.io.ResolverUtil] [main] [DEBUG] [org.apache.ibatis.io.ResolverUtil] [addIfMatching] [287] : Checking to see if class SomeClass matches criteria [is assignable to Object]

In NB 18 due to the swtich from target/classes to maven repository jar the second line will not appear, SomeClass will not be found by scanning, and thus ClassNotFoundException will be thrown when loading result map xml.

[morvael]

I actually worked with compile on save disabled for a long time, since it caused some bug (long forgotten what it was), but the IDE simply used last version of target/classes from regular build and was able to scan them properly. Now it somehow can't do it when pointed to actual jar.

[morvael]

SomeClass is in project A. main is in a test class in project B.

    public static void main(String[] args) {
        boolean found = false;
        ResolverUtil<Object> resolver = new ResolverUtil<>();
        resolver.findAnnotated(Alias.class, "some.package");
        for (Class<?> c : resolver.getClasses()) {
            if (c.getSimpleName().equals("SomeClass")) {
                found = true;
                break;
            }
        }
        System.out.println(found ? "class found" : "class not found");
    }
    ```

When project A is set to compile on save disabled in NB 18 the result will be "class not found". With compile on save enabled in NB 18 or in NB 17 (regardless of compile on save setting) the result will be "class found".

[morvael]

So forcing VFS class used by ResolverUtil to use DefaultVFS implementation for "run from IDE" classes (VFS.addImplClass(DefaultVFS.class);) helps to solve this problem. JBoss6VFS seems unable to handle repository jars pointed by class path in NB 18, and unfortunately is the first implementation VFS tries to load and use by default.