I've been working on an Eclipse plugin codebase that builds with Maven Tycho. I can provide some snippets that anyone asks for, but you can get the code at https://git.opendaylight.org/gerrit/#/admin/projects/yangide (I believe that should be open).
I usually test it with an "Eclipse Application" launch config, loading all the plugins in the workspace. This works.
I sometimes test it by referencing the update site zip that I build locally. This works most of the time.
Recently, someone else I work with has deployed the update site to a public URL (https://nexus.opendaylight.org/content/sites/p2repos/org.opendaylight.yangide). This was built from master.
When I install from this into a standalone Eclipse, at some point after startup I see the following error:
Exception:java.lang.LinkageError: org/antlr/v4/runtime/TokenStream
at org.antlr.v4.runtime.Parser.setInputStream(Parser.java:530)
at org.antlr.v4.runtime.Parser.<init>(Parser.java:182)
at org.opendaylight.yangtools.antlrv4.code.gen.YangParser.<init>(YangParser.java:188)
I've actually seen this same exception sometimes when testing with the locally built update site zip, but rarely. I'm seeing it every time with this deployed update site.
So I understand that "Linkage Error" means that the class had already been loaded by another classloader which conflicts with this.
So, I started it up again with "-verbose:class" to at least see some information about the loading of this class.
From this output, I saw the following:
[Loaded org.antlr.v4.runtime.TokenStream from file:/home/opnfv/frameworks/eclipse-neon/java-mars/eclipse/../../../../.p2/pool/plugins/net.sf.eclipsecs.checkstyle_6.16.0.201603042321/checkstyle-6.16.1-all.jar]
[Loaded org.antlr.v4.runtime.TokenStream from file:/home/opnfv/frameworks/eclipse-neon/java-mars/eclipse/configuration/org.eclipse.osgi/605/0/.cp/libs/antlr4-runtime-4.5.1.jar]
[Loaded org.antlr.v4.runtime.TokenStream from file:/home/opnfv/.m2/repository/org/antlr/antlr4-runtime/4.5.1/antlr4-runtime-4.5.1.jar]
Note that this plugin obtains several jars from a Maven repo, as opposed to a p2 repo, including the "antlr4-runtime-4.5.1.jar" file. Most of these jars are not available in a public p2 repo. One of the plugins uses the "copy" and "copy-dependencies" goals of the "maven-dependency-plugin" to get Maven artifacts, and then specifies the local paths to those jars in the "Bundle-ClassPath" property in the META-INF/MANIFEST.MF file. other plugins in the codebase specify that plugin as a dependency.
Update:
Note that I sometimes see the following variation of this in the log:
Exception in thread "Yang indexer" java.lang.LinkageError: loader constraint violation: loader (instance of org/eclipse/osgi/internal/loader/EquinoxClassLoader) previously initiated loading for a different type with name "org/antlr/v4/runtime/TokenStream"
at java.lang.ClassLoader.defineClass1(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:760)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.defineClass(ModuleClassLoader.java:272)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.defineClass(ClasspathManager.java:632)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findClassImpl(ClasspathManager.java:588)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClassImpl(ClasspathManager.java:540)
at org.eclipse.osgi.internal.loader.classpath.ClasspathManager.findLocalClass(ClasspathManager.java:527)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.findLocalClass(ModuleClassLoader.java:324)
at org.eclipse.osgi.internal.loader.BundleLoader.findLocalClass(BundleLoader.java:327)
at org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:402)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:352)
at org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:344)
at org.eclipse.osgi.internal.loader.ModuleClassLoader.loadClass(ModuleClassLoader.java:160)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
at org.antlr.v4.runtime.Parser.setInputStream(Parser.java:530)
Update:
I realized that it might be useful to add "-verbose:class" to the launch config test case, because that is not having this problem. When I searched for the same class reference in the output, I only saw one occurrence:
[Loaded org.antlr.v4.runtime.TokenStream from file:/home/opnfv/workspace3/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/../../../../../../../media/sf_laptophome/git/yangide/plugins/com.cisco.yangide.yangparser/libs/antlr4-runtime-4.5.1.jar]
Remember that this is just loading the plugins from the workspace. This path is essentially in my workspace. In any case, it never tried to load it from those other two jar files.
This was because the Checkstyle Eclipse plugin "leaked" another version of ANTLR into this other (yangide) Eclipse plugin which uses a Package-Import.
Related
My projects look like this
EAR_proj
lib/
3rd party jars
EJB_proj
Web_proj (a web service with WSDL)
Common_proj1
Common_proj2
EAR_proj has Deployment Assembly contains all other projects
All projects have "EAR library" in their classpath for the 3rd party libraries.
The Web_proj has Deployment Assembly contains Common_proj1 and Common_proj2 (in its MANIFEST.MF)
However when I deploy the Web_project to the server (within RAD), I kept getting NoClassDefFoundError for 1 class that resides within Common_proj1.
Looking at WebSphere ffdc error file, it says
FFDC Exception:java.io.FileNotFoundException SourceId:com.ibm.ws.websvcs.utils.Axis2Utils.getApplicationClassPath ProbeId:874
java.io.FileNotFoundException: Common_proj1\bin (Access is denied.)
The other ffdc file indicate Common_proj1/bin is on the classpath of some ClassLoader...I'm not sure why it doesn't just treat Common_proj1 as a jar file. Is it because this happen within the IDE?
The server Classloader policy is set to "Single" and "Classes loaded with parent class loader first" policy
Turn out this is a RAD problem after upgrading to a newer JDK.
http://www-01.ibm.com/support/docview.wss?uid=swg21667356
Adding the attribute wsldLocation in the web service implementation class solves the problem.
We have renewed security certificates in our java applications and suddenly we have started receiving below mentioned exception:
java.lang.SecurityException: class "org.hibernate.cfg.Configuration"'s signer information does not match signer information of other classes in the same package
at java.lang.ClassLoader.checkCerts(ClassLoader.java:806) [rt.jar:1.6.0_37]
at java.lang.ClassLoader.preDefineClass(ClassLoader.java:487) [rt.jar:1.6.0_37]
at java.lang.ClassLoader.defineClassCond(ClassLoader.java:625) [rt.jar:1.6.0_37]
at java.lang.ClassLoader.defineClass(ClassLoader.java:615) [rt.jar:1.6.0_37]
at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:344)
We use ANT tool to build our code. I found some links over the SO describing the similar issue. Bur I am not sure how to resolve issue which is related to hibernate jars. Please let me know, if you have any idea.
Might be that your class org.hibernate.cfg.Configuration doesn't get loaded from the jar that you're expecting to do so.
Had the same problem when our program was loading some utility classes for JavaMail and it turned out that after switching over to Maven for project configuration management, some of our Jetty dependencies were including the jar javax.mail.glassfish, thus conflicting with the explicit mail dependencies.
To find out which jars are actually loaded when launching the java program from console, you can use the -verbose:class option when starting the Java VM (as described here).
I had an additional jar file in WEB-INF/lib/wsdl4j.jar
After deploy custom rule (like https://github.com/SonarSource/sonar-java/blob/master/java-checks/src/main/java/org/sonar/java/checks/UselessImportCheck.java), when I start SonarQube 4.2, following exception is thrown during sonar start:
Caused by: java.lang.ClassNotFoundException: com.sonar.sslr.api.AstAndTokenVisitor
at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50) ~[plexus-classworlds-2.2.3.jar:na]
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:244) ~[plexus-classworlds-2.2.3.jar:na]
at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:230) ~[plexus-classworlds-2.2.3.jar:na]
... 44 common frames omitted
Above mentioned class should be found in sslr-core-1.19.2.jar, which I found in location sonarqube-4.2/web/deploy/plugins/squidjava/META-INF/lib/sslr-core-1.19.2.jar
Am I missing some step to enhnance default sonar libraries?
Currently installed plugins are(sonarqube-4.2/extensions/plugins):
sonarqube-4.2/extensions/plugins/sonar-checkstyle-plugin-2.1.jar
sonarqube-4.2/extensions/plugins/sonar-web-plugin-2.1.jar
sonarqube-4.2/extensions/plugins/sonar-jacoco-plugin-2.2.1.jar
sonarqube-4.2/extensions/plugins/sonar-java-plugin-2.2.1.jar
sonarqube-4.2/extensions/plugins/sonar-surefire-plugin-2.2.1.jar
sonarqube-4.2/extensions/plugins/sonar-pmd-plugin-2.2.jar
sonarqube-4.2/extensions/plugins/sonar-findbugs-plugin-2.2.1.jar
sonarqube-4.2/extensions/plugins/sonar-squid-java-plugin-2.2.1.jar
What should I do to prevent above mentioned exception(except undeploy mentioned custom plugin)?
Should be necessary libraries bundled directly in to the custom plugin? I expected sonar to have such libraries bundled.
Finally I found solution/explanation for the problem:
sonarqube-4.2/web/deploy/plugins/ directory is dynamically updated during sonar start from the sonarqube-4.2/extensions/plugins directory. Every plugin should have lib directory in his META-INF jar.Such lib directory should contain all necessary libraries.
In my case:
META-INF/lib/asm-5.0.1.jar
META-INF/lib/java-checks-2.2.1.jar
META-INF/lib/java-squid-2.2.1.jar
META-INF/lib/jaxen-1.1.4.jar
META-INF/lib/sslr-core-1.19.2.jar
META-INF/lib/sslr-squid-bridge-2.3.jar
META-INF/lib/sslr-xpath-1.19.2.jar
And META-INF/MANIFEST.MF must besides othet important definitions contain link to these libraries:
Plugin-Dependencies: META-INF/lib/java-checks-2.2.1.jar META-INF/lib/j
axen-1.1.4.jar META-INF/lib/sslr-squid-bridge-2.3.jar META-INF/lib/ss
lr-xpath-1.19.2.jar META-INF/lib/asm-5.0.1.jar META-INF/lib/sslr-core
-1.19.2.jar META-INF/lib/java-squid-2.2.1.jar
After these steps deploy success and plugin is ready to be used.
Above mentioned fact is may be clear for MAVEN users (there is lot of pom files),but gradle users must create such builds on their own and this information may be useful for them.
Good luck!
I am working on some migration project, involves moving around quite a few stuff from Ant/CVS/Jboss4/Java5 to Maven/SVN/Jboss7/Java6 - this gets nasty.
First step, I am working on moving the ant build to maven - that it in iteslf involve a lot of complication. Now that I get the ear file built, and I compared it with the ear from ant build, I think I got it good with the maven build.
Now, deploying on Jboss4 first, I encouter
[ejb.EJBDeployer.verifier] EJB spec violation:
Warning: The message driven bean must declare one onMessage() method.
2011-11-08 15:25:03,079 ERROR (Thread: main) [jboss.deployment.MainDeployer] Could not create deployment: file:/opt/jboss-4.0.3SP1/server/default/tmp/deploy/tmp46514Billing-EAR-1.0.ear-contents/processsubscriptionbean-1.0.jar
org.jboss.deployment.DeploymentException: Verification of Enterprise Beans failed, see above for error messages.
at org.jboss.ejb.EJBDeployer.create(EJBDeployer.java:575)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:141)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:80)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:118)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:127)
at org.jboss.mx.interceptor.DynamicInterceptor.invoke(DynamicInterceptor.java:80)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:74)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:245)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:644)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:176)
at $Proxy24.create(Unknown Source)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:935)
at org.jboss.deployment.MainDeployer.create(MainDeployer.java:925)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:789)
I came across this thread jBoss deployment of message-driven bean spec violation - so I figured I was using the wrong library on my new maven build, I replaced it and made sure it's using the same javax.jms library (this now points to the same jar containing javax.jms.Message as the original ant build) - in fact I simply grabbed the jar referenced by the ant build and upload it to maven repo and reference it from my maven build.
But I still encounter the above problem. The original ant-build would deploy with no problem, but currently I am stuck at this issue for the maven-build ear.
Any suggestion on what other steps i can take to make sure there are no different class files issue? Thanks!
Is the javax.jms library being packaged in your ear (jboss-j2ee.jar, jboss-client.jar, etc)? If so, you don't want that since you want to use the one provided by the app server. You can fix this by changing the dependency in your pom to have the <scope>provided</scope> for anything that shouldn't be in your ear.
I am trying out m2eclipse, the Eclipse plugin for Maven, and have noticed that the resources are now excluded from the build path of all my projects.
I have seen a question on the M2Eclipse FAQ page which seems to deal with this exact question, but the answer (paraphrased) seems to say that this is intentional to allow resource filtering, and everything Should Just Work.
However, when I run my application from within Eclipse, lots of my resources in dependent projects are failing to get found by my application.
I have tried my usual Eclipse waving-a-rubber-chicken actions (cleaning all projects, starting with -clean) to no avail. I'm sure I'm missing something fairly simple. Does anyone have any suggestions?
EDIT: Some digging in the m2 console has revealed that one of the projects is not building correctly. I get a ClassNotFoundException when it tries to find org.apache.maven.plugin.MojoFailureException in a custom plugin used to build one of the projects.
org.apache.maven.lifecycle.LifecycleExecutionException: Internal error in the plugin manager executing goal 'ourdemain:ourcustomplugin:2.0:process': Mojo execution failed.
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:505)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegmentForProject(DefaultLifecycleExecutor.java:265)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeTaskSegments(DefaultLifecycleExecutor.java:191)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.execute(DefaultLifecycleExecutor.java:149)
at org.apache.maven.DefaultMaven.execute_aroundBody0(DefaultMaven.java:223)
at org.apache.maven.DefaultMaven.execute_aroundBody1$advice(DefaultMaven.java:304)
at org.apache.maven.DefaultMaven.execute(DefaultMaven.java:1)
at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody2(MavenEmbedder.java:904)
at org.apache.maven.embedder.MavenEmbedder.execute_aroundBody3$advice(MavenEmbedder.java:304)
at org.apache.maven.embedder.MavenEmbedder.execute(MavenEmbedder.java:1)
at org.maven.ide.eclipse.internal.project.DefaultBuildParticipant$1.execute(DefaultBuildParticipant.java:130)
at org.maven.ide.eclipse.internal.project.MavenProjectManagerImpl.execute(MavenProjectManagerImpl.java:986)
at org.maven.ide.eclipse.internal.project.MavenProjectFacade.execute(MavenProjectFacade.java:320)
at org.maven.ide.eclipse.internal.project.DefaultBuildParticipant.executePostBuild(DefaultBuildParticipant.java:116)
at org.maven.ide.eclipse.internal.project.DefaultBuildParticipant.build(DefaultBuildParticipant.java:80)
at org.maven.ide.eclipse.internal.builder.MavenBuilder.build(MavenBuilder.java:84)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:633)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:170)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:201)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:253)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:256)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:309)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:341)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:140)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:238)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: org.apache.maven.plugin.PluginExecutionException: Mojo execution failed.
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:601)
at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoalAndHandleFailures(DefaultLifecycleExecutor.java:498)
... 27 more
Caused by: org.apache.maven.plugin.MojoExecutionException: org/apache/maven/plugin/MojoFailureException
at org.codehaus.mojo.ruby.DefaultRubyMojo.execute(DefaultRubyMojo.java:98)
at org.apache.maven.plugin.DefaultPluginManager.executeMojo(DefaultPluginManager.java:579)
... 28 more
Caused by: java.lang.NoClassDefFoundError: org/apache/maven/plugin/MojoFailureException
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:2389)
at java.lang.Class.getConstructor0(Class.java:2699)
at java.lang.Class.getConstructor(Class.java:1657)
at java.lang.reflect.Proxy.newProxyInstance(Proxy.java:587)
at org.jruby.javasupport.Java.new_proxy_instance(Java.java:570)
at org.jruby.javasupport.JavaInvokerSnew_proxy_instancexx1.call(Unknown Source)
at org.jruby.runtime.callback.InvocationCallback.execute(InvocationCallback.java:49)
at org.jruby.internal.runtime.methods.FullFunctionCallbackMethod.internalCall(FullFunctionCallbackMethod.java:79)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:79)
at org.jruby.evaluator.EvaluationState.callNode(EvaluationState.java:577)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:206)
at org.jruby.evaluator.EvaluationState.setupArgs(EvaluationState.java:2182)
at org.jruby.evaluator.EvaluationState.attrAssignNode(EvaluationState.java:481)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:191)
at org.jruby.evaluator.EvaluationState.blockNode(EvaluationState.java:522)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:200)
at org.jruby.evaluator.EvaluationState.eval(EvaluationState.java:163)
at org.jruby.internal.runtime.methods.DefaultMethod.internalCall(DefaultMethod.java:167)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:79)
at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:125)
at org.jruby.evaluator.EvaluationState.callNode(EvaluationState.java:564)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:206)
at org.jruby.evaluator.EvaluationState.callNode(EvaluationState.java:544)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:206)
at org.jruby.evaluator.EvaluationState.localAsgnNode(EvaluationState.java:1230)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:285)
at org.jruby.evaluator.EvaluationState.rescueNode(EvaluationState.java:1522)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:349)
at org.jruby.evaluator.EvaluationState.ensureNode(EvaluationState.java:980)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:246)
at org.jruby.evaluator.EvaluationState.eval(EvaluationState.java:163)
at org.jruby.internal.runtime.methods.DefaultMethod.internalCall(DefaultMethod.java:167)
at org.jruby.internal.runtime.methods.DynamicMethod.call(DynamicMethod.java:79)
at org.jruby.internal.runtime.methods.DefaultMethod.call(DefaultMethod.java:125)
at org.jruby.evaluator.EvaluationState.fCallNode(EvaluationState.java:1019)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:252)
at org.jruby.evaluator.EvaluationState.blockNode(EvaluationState.java:522)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:200)
at org.jruby.evaluator.EvaluationState.rootNode(EvaluationState.java:1622)
at org.jruby.evaluator.EvaluationState.evalInternal(EvaluationState.java:355)
at org.jruby.evaluator.EvaluationState.eval(EvaluationState.java:163)
at org.jruby.Ruby.eval(Ruby.java:274)
at org.codehaus.plexus.component.jruby.JRubyRuntimeInvoker.runInterpreter(JRubyRuntimeInvoker.java:392)
at org.codehaus.plexus.component.jruby.JRubyRuntimeInvoker.invoke(JRubyRuntimeInvoker.java:313)
at org.codehaus.mojo.ruby.DefaultRubyMojo.execute(DefaultRubyMojo.java:81)
... 29 more
Caused by: java.lang.ClassNotFoundException: org.apache.maven.plugin.MojoFailureException
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:306)
at java.lang.ClassLoader.loadClass(ClassLoader.java:251)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:319)
... 75 more
The resource filtering mentioned in the FAQ is run whenever the Maven builder is run on the project. In practice I've found this to be more trouble than it's worth as the Maven builder runs quite slowly, and is only run when configured (which by default is only on a full build), leaving you to scratch your head and wonder why your changes aren't picked up.
I tend to modify the Eclipse classpath to include src/main/resources. This is sufficient for most use cases.
For the cases where the simple approach doesn't work (for example if a dependent project has some complicated resource processing), I do as Robert suggests and turn off workspace resolution, then install the dependency to the local repository so it is included in the Maven classpath container.
Try switching between the embedded ( 3.0 AFAIK ) Maven runtime and the one you use to perform your builds ( locally installed ).
Maven installations http://img150.imageshack.us/img150/6193/m2eclipseinstallations.png