Eclipse – m2eclipse: How to set Eclipse project settings when importing a maven project

eclipsem2eclipsemaven-2

Using m2eclipse Eclipse plugin, everybody on the dev team should be able to checkout source code, import Maven project in Eclipse and be good to go.

I saw m2eclipse is being merged into Eclipse 3.7, and maven-eclipse-plugin won't be maintained any longer, so I'm looking for a m2eclipse-based solution (without running "mvn eclipse:clean eclipse:eclipse" before project import, which is what maven-eclipse-plugin does).

maven-eclipse-plugin allows this in pom.xml

<additionalConfig>
<file>
    <name>.settings/com.google.gdt.eclipse.core.prefs</name>
    <content><![CDATA[
        eclipse.preferences.version=2
        jarsExcludedFromWebInfLib=
        warSrcDir=${project.build.directory}/${project.build.finalName}
        warSrcDirIsOutput=true
        ]]>
    </content>
</file>

The more general question is How would m2eclipse do something similar?
For some cases, just saving the eclipse .settings/prefs file works (e.g. org.eclipse.jdt.ui.prefs), but in this case, com.google.gdt.eclipse.core.prefs is always overwritten on m2eclipse project import.

A specific question is asked here, with no reply.
Thanks!

UPDATE: Not possible now, see request

Best Answer

There are answers to this topic in Can I Configure m2eclipse through pom.xml?: Completely automatic configuration can only be achieved with a ProjectConfigurator. But there is a solution based on AntRun and XMLTask even for the Google Eclipse Plugin GEP. It needs manual triggering only once after checkout.

Related Solutions

Eclipse – How to you speed up Eclipse

The three most influential factors for Eclipse speed are:

Using the latest version of Eclipse (2020-06 as on 26 June 2020)
Note that David Balažic's comment (July 2014) contradicts that criteria which was working six years ago:

The "same" workspace in Indigo (3.7.2) SR2 loads in 4 seconds, in Kepler SR2 (4.3.2) in 7 seconds and in Luna (4.4.0) in 10 seconds. All are Java EE bundles. Newer versions have more bundled plugins, but still the trend is obvious. (by "same" workspace I mean: same (additionally installed) plugins used, same projects checked out from version control).

Launching it with the latest JDK (Java 14 at the time of writing, which does not prevent you to compile in your Eclipse project with any other JDK you want: 1.4.2, 1.5, 1.6 older...)
```
  -vm jdk1.6.0_10\jre\bin\client\jvm.dll
```
Configuring the eclipse.ini (see this question for a complete eclipse.ini)
```
  -Xms512m
  -Xmx4096m
  [...]
```

The Xmx argument is the amount of memory Eclipse will get (in simple terms). With -Xmx4g, it gets 4 GB of RAM, etc.

Note:

Referring to the jvm.dll has advantages:

Splash screen coming up sooner.
Eclipse.exe in the process list instead of java.exe.
Firewalls: Eclipse wants access to the Internet instead of Java.
Window management branding issues, especially on Windows and Mac.

Dec. 2020, Udo conforms in the comments

From version 4.8 (Photon) an up there was a steady speed gain after each version.
The main platform was optimized every release to load faster, enable more features for the dark theme and to add more features for newer Java versions for the Java development tools.
Especially with-in the last 3 versions the startup time was increased a lot. There should be a significant increase in start-up time with the newest version of Eclipse 2020-12.

In my experience it started a lot faster with each new version.
But: There are still plug-ins which do not follow the new way of using the Eclipse API and are therefore still slow to start.
Since the change to Java 11 as the minimum runtime version starting from Eclipse version 2020-09 at least the core system uses the newer features of the JVM. It is up to the providers of the other plug-ins to upgrade to newer APIs and to use the full power of modern CPUs (e.g. concurrent programming model).

Java – How to create an executable JAR with dependencies using Maven

<build>
  <plugins>
    <plugin>
      <artifactId>maven-assembly-plugin</artifactId>
      <configuration>
        <archive>
          <manifest>
            <mainClass>fully.qualified.MainClass</mainClass>
          </manifest>
        </archive>
        <descriptorRefs>
          <descriptorRef>jar-with-dependencies</descriptorRef>
        </descriptorRefs>
      </configuration>
    </plugin>
  </plugins>
</build>

and you run it with

mvn clean compile assembly:single

Compile goal should be added before assembly:single or otherwise the code on your own project is not included.

See more details in comments.

Commonly this goal is tied to a build phase to execute automatically. This ensures the JAR is built when executing mvn install or performing a deployment/release.

<plugin>
  <artifactId>maven-assembly-plugin</artifactId>
  <configuration>
    <archive>
      <manifest>
        <mainClass>fully.qualified.MainClass</mainClass>
      </manifest>
    </archive>
    <descriptorRefs>
      <descriptorRef>jar-with-dependencies</descriptorRef>
    </descriptorRefs>
  </configuration>
  <executions>
    <execution>
      <id>make-assembly</id> <!-- this is used for inheritance merges -->
      <phase>package</phase> <!-- bind to the packaging phase -->
      <goals>
        <goal>single</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Best Answer

Related Solutions

Eclipse – How to you speed up Eclipse

Java – How to create an executable JAR with dependencies using Maven

Related Topic