Eclipse – Maven Eclipse plugin and classpath issues in Eclipse

classpatheclipsemaven-2plugins

I am using Eclipse 3.51, Maven 2.0.9, Java 1.4, with the Maven Eclipse plugin 2.7 with WTP 2.0 (not m2Eclipse).

I have a flat multi module project that is set up as follows (module Parent with the parent pom, module A and B is dependent on C).

Importing the four modules in for the first time will show compile errors as expected since I have not ran the eclipse plugin. With my local repository empty, running eclipse clean will resolve all compile errors and dependencies within the my local workspace.

If I were to make some minor code changes to module B and run the eclipse plugin again, compile errors would show up in module A and B. Compile errors about classes that cannot be found. Its like module C is no longer in the classpath for A and B to see.

I look at the .classpath file and its definitely looking at the right modules in the Eclipse workspace.

If I delete the maven repository and do the eclipse clean again, the compile errors about unresolved classes are fixed. Also, if I run the eclpse clean command with the useProjectReferences flag to false and then rerun it with true, Eclipse would rebuild my workspace and the errors will go away.

Whats going on?

Best Answer

Importing the four modules in for the first time will show compile errors as expected since I have not ran the eclipse plugin. With my local repository empty, running eclipse clean will resolve all compile errors and dependencies within the my local workspace.

So far so good. Just one question: by eclipse clean, you don't mean eclipse:clean but clean under Eclipse, right?

If I were to make some minor code changes to module B and run the eclipse plugin again, compile errors would show up in module A and B. Compile errors about classes that cannot be found. Its like module C is no longer in the classpath for A and B to see.

I'm not sure why you run the maven eclipse plugin after a minor code changes to module B but, let's say you have to e.g. because you added a dependency (it would have been helpful to mention the goal you run but never mind). When using the maven eclipse plugin with a multi projects build, it will use project references by default at the Eclipse level (i.e. A and B depend on the compiled classes of C, not on C JAR). And because Maven and Eclipse share the same target/classes folder, a clean or compile at the Maven level can confuse Eclipse. It doesn't see the compiled classes anymore and won't compile them by himself (because the change didn't occur in Eclipse). In that case, an Eclipse clean or rebuild (i.e. at the Eclipse level) should solve the problem.

I look at the .classpath file and its definitely looking at the right modules in the Eclipse workspace.

Yes, that's not the problem. The problem comes from the fact that both Eclipse and Maven share the same folder for compile classes.

If I delete the maven repository and do the eclipse clean again, the compile errors about unresolved classes are fixed.

You really don't have to do this and I don't get what the maven repository has to do with this if you use project references. Performing a clean and/or rebuilding all projects under Eclipse should fix the problem.

Also, if I run the eclpse clean command with the useProjectReferences flag to false and then rerun it with true, Eclipse would rebuild my workspace and the errors will go away.

Are you using project references or not? Again, next time, maybe provide your plugin configuration in your question, this may help. Anyway, you should not have to touch this between builds. Decide if you want to use project references (I think it's more convenient, without them you'll need to mvn install C to make changes available for A and B) and stick with this configuration. After a mvn build, a rebuild of the Eclipse workspace should be enough.

PS: Note that you could configure the maven eclipse plugin to use a custom buildOutputDirectory, for example target/eclipse-classes but this has other drawbacks (I wasn't doing this).

Related Solutions

Java – Including all the jars in a directory within the Java classpath

Using Java 6 or later, the classpath option supports wildcards. Note the following:

Use straight quotes (")
Use *, not *.jar

Windows

java -cp "Test.jar;lib/*" my.package.MainClass

Unix

java -cp "Test.jar:lib/*" my.package.MainClass

This is similar to Windows, but uses : instead of ;. If you cannot use wildcards, bash allows the following syntax (where lib is the directory containing all the Java archive files):

java -cp "$(printf %s: lib/*.jar)"

(Note that using a classpath is incompatible with the -jar option. See also: Execute jar file with multiple classpath libraries from command prompt)

Understanding Wildcards

From the Classpath document:

Class path entries can contain the basename wildcard character *, which is considered equivalent to specifying a list of all the files in the directory with the extension .jar or .JAR. For example, the class path entry foo/* specifies all JAR files in the directory named foo. A classpath entry consisting simply of * expands to a list of all the jar files in the current directory.

A class path entry that contains * will not match class files. To match both classes and JAR files in a single directory foo, use either foo;foo/* or foo/*;foo. The order chosen determines whether the classes and resources in foo are loaded before JAR files in foo, or vice versa.

Subdirectories are not searched recursively. For example, foo/* looks for JAR files only in foo, not in foo/bar, foo/baz, etc.

The order in which the JAR files in a directory are enumerated in the expanded class path is not specified and may vary from platform to platform and even from moment to moment on the same machine. A well-constructed application should not depend upon any particular order. If a specific order is required then the JAR files can be enumerated explicitly in the class path.

Expansion of wildcards is done early, prior to the invocation of a program's main method, rather than late, during the class-loading process itself. Each element of the input class path containing a wildcard is replaced by the (possibly empty) sequence of elements generated by enumerating the JAR files in the named directory. For example, if the directory foo contains a.jar, b.jar, and c.jar, then the class path foo/* is expanded into foo/a.jar;foo/b.jar;foo/c.jar, and that string would be the value of the system property java.class.path.

The CLASSPATH environment variable is not treated any differently from the -classpath (or -cp) command-line option. That is, wildcards are honored in all these cases. However, class path wildcards are not honored in the Class-Path jar-manifest header.

Note: due to a known bug in java 8, the windows examples must use a backslash preceding entries with a trailing asterisk: https://bugs.openjdk.java.net/browse/JDK-8131329

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).

Best Answer

Related Solutions

Java – Including all the jars in a directory within the Java classpath

Eclipse – How to you speed up Eclipse

Related Topic