Support configuration via <projectdir>/.settings/org.eclipse.jdt.core.prefs

[markiewb]

Configuration example: org.eclipse.jdt.core.prefs

[markiewb]

[markiewb]

Try out the draft https://github.com/markiewb/eclipsecodeformatter_for_netbeans/releases/download/v1.10.1-withprefs/de-markiewb-netbeans-plugins-eclipse-formatter.nbm and give me feedback!

[jtulach]

Finally I got time to try this. Looks like your plugin is fighting with our command line tool - they disagree on the formatting. To reproduce:

$ mx netbeansinit
$ mx eclipseformat -e /path_to/eclipse/
$ nb truffle/com.oracle.truffle.api/
# do some edits, reformat - I tried CompilerAsserts.java and the code got completely
# rearranged
$ mx eclipseformat -e /path_to/eclipse/

The code modified by the IDE is reformatted again and this goes on and on.

[markiewb]

@jtulach:

1. Can you please diff the files? What is the difference? Only linefeeds? If linefeeds, then I address this in Support configuration of linefeed #71
2. mx eclipseformat -e /path_to/eclipse -> Which Eclipse version is used? The plugin currently uses the formatter from "Eclipse 4.5.1 (Mars.1)"
3. mx eclipseformat -e /path_to/eclipse -> Can you point me to the sources, which show me, what this command does in detail

[jtulach]

The changes are mostly in formatting comments (that is the biggest pain we have with Eclipse formatter):

diff --git a/truffle/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerAsserts.java b/truffle/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerAsserts.java
index 7ac181e..e40fa37 100644
--- a/truffle/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerAsserts.java
+++ b/truffle/com.oracle.truffle.api/src/com/oracle/truffle/api/CompilerAsserts.java
@@ -25,30 +25,34 @@
 package com.oracle.truffle.api;

 /**
- * Assertions about the code produced by the Truffle compiler. All operations have no effect when
- * either executed in the interpreter or in the compiled code. The assertions are checked during
- * code generation and the Truffle compiler produces for failing assertions a stack trace that
- * identifies the code position of the assertion in the context of the current compilation.
+ * Assertions about the code produced by the Truffle compiler. All operations
+ * have no effect when either executed in the interpreter or in the compiled
+ * code. The assertions are checked during code generation and the Truffle
+ * compiler produces for failing assertions a stack trace that identifies the
+ * code position of the assertion in the context of the current compilation.
  *
  */
 public final class CompilerAsserts {
+
     private CompilerAsserts() {
     }

     /**
-     * Assertion that this code position should never be reached during compilation. It can be used
-     * for exceptional code paths or rare code paths that should never be included in a compilation
-     * unit. See {@link CompilerDirectives#transferToInterpreter()} for the corresponding compiler
-     * directive.
+     * Assertion that this code position should never be reached during
+     * compilation. It can be used for exceptional code paths or rare code paths
+     * that should never be included in a compilation unit. See
+     * {@link CompilerDirectives#transferToInterpreter()} for the corresponding
+     * compiler directive.
      */
     public static void neverPartOfCompilation() {
     }

     /**
-     * Assertion that this code position should never be reached during compilation. It can be used
-     * for exceptional code paths or rare code paths that should never be included in a compilation
-     * unit. See {@link CompilerDirectives#transferToInterpreter()} for the corresponding compiler
-     * directive.
+     * Assertion that this code position should never be reached during
+     * compilation. It can be used for exceptional code paths or rare code paths
+     * that should never be included in a compilation unit. See
+     * {@link CompilerDirectives#transferToInterpreter()} for the corresponding
+     * compiler directive.
      *
      * @param message text associated with the bailout exception
      */
@@ -56,7 +60,8 @@ public final class CompilerAsserts {
     }

     /**
-     * Assertion that the corresponding value is reduced to a constant during compilation.
+     * Assertion that the corresponding value is reduced to a constant during
+     * compilation.
      *
      * @param value the value that must be constant during compilation
      */
@@ -67,8 +72,8 @@ public final class CompilerAsserts {
     }

     /**
-     * Assertion that the corresponding value is reduced to a constant during the initial partial
-     * evaluation phase.
+     * Assertion that the corresponding value is reduced to a constant during
+     * the initial partial evaluation phase.
      *
      * @param value the value that must be constant during compilation
      */

[jtulach]

The (python) sources for mx are at https://github.com/graalvm/mx/
The Eclipse in /path_to/eclipse is Luna on my computer.

[markiewb]

Hej @jtulach: You are using Luna. So I guess the formatter engine has been changed between Mars and Luna. Can you please try out (only try for analyzing the problem) to use a Mars installation? And tell me if the formatting is now correct.

If so I could provide another option in the plugin to use the external Eclipse installation. I filed #72

BTW:
I guess it is not your fault/decision, but I am very shocked that the "build"-script mx.py heavily depends on parsing the eclipse-configuration files. IMO that is not maintainable. And schizophrenic: Even the Eclipse developers in your team have to invoke the mx-goals to generate their configuration to load their projects into their Eclipse IDE correctly.
https://github.com/graalvm/mx/blob/master/mx.py#L1912
https://github.com/graalvm/mx/blob/master/mx.py#L7852

[jtulach]

Yes, the project is IDE neutral. Every IDE user needs to invoke "mx ideinit".

[jtulach]

Thanks for trying to support our workflow.

[markiewb]

@jtulach: Have you tried #67 (comment) ? Does Luna works for you? If yes, then I could try to bundle this engine in some other way - #72

[jtulach]

Looks like Luna and Mars RC1 disagree on the formating. When I do:

truffle$ git checkout 8495d7692f7a0ef12a696af2aed21f4db4d69658
truffle$ mx eclipseformat  -e ~/bin/eclipse
No files modified
truffle$ mx eclipseformat  -e ~/bin/eclipse-mars/
Wrote backup of 52 modified files to /mnt/data/src/truffle/eclipseformat.backup.zip

The modified files differ mostly in comments:

 - truffle/com.oracle.truffle.api.instrumentation/src/com/oracle/truffle/api/instrumentation/SuppressFBWarnings.java
Changes:
--- 
+++ 
@@ -33,8 +33,8 @@
 @Retention(RetentionPolicy.CLASS)
 @interface SuppressFBWarnings {
     /**
-     * The set of FindBugs <a
-     * href="http://findbugs.sourceforge.net/bugDescriptions.html">warnings</a> that are to be
+     * The set of FindBugs
+     * <a href="http://findbugs.sourceforge.net/bugDescriptions.html">warnings</a> that are to be
      * suppressed in annotated element. The value can be a bug category, kind or pattern.
      */
     java.lang.String[] value();

I'll ask what is the team's policy with respect to most recent version of Eclipse.

[markiewb]

@jtulach: Ok, good to know that the formatter engine is the culprit. In the worstcase you could patch the plugin yourself. Fork this plugin, replace all the wrapped jars with those from Luna (to https://github.com/markiewb/eclipsecodeformatter_for_netbeans/tree/master/release/modules/ext) and build it again.

[jtulach]

FYI: graalvm/mx#52