Re: [recommenders-dev] Need help to collect completion proposals made by

[Andreas Sewe <andreas.sewe@xxxxxxxxxxxxxx>]

Hi Muhammad,

> Good day. I have tried to use the new Code Recommenders code base
> (2.0). I follow the steps described here:
> http://git.eclipse.org/c/recommenders/org.eclipse.recommenders.git/about/
> 
> After that I  include the org.eclipse.recommenders.examples to the
> build path. But there are some errors in the
> EclipseOrgCallRecommenderMain.java file (only in this file).

yes, I am afraid the examples haven't been looked at in a while. if you
want to see them updated, please file an enhancement request in Bugzilla
[1].

> I ignore
> the error and run SingleZipCallRecommenderMain.java file. But it gives
> me the following error:
> 
> //+++++++++++++++++++++++++++++++++++++++++
> SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
> 
> SLF4J: Defaulting to no-operation (NOP) logger implementation
> 
> SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for
> further details.
> 
> Exception in thread "main" java.lang.NoSuchMethodError:
> com.google.common.cache.CacheBuilder.maximumSize(J)Lcom/google/common/cache/CacheBuilder;
> 
> at org.eclipse.recommenders.calls.SingleZipCallModelProvider.<init>(SingleZipCallModelProvider.java:51)
> 
> at org.eclipse.recommenders.examples.calls.SingleZipCallRecommender.<init>(SingleZipCallRecommender.java:34)
> 
> at org.eclipse.recommenders.examples.calls.SingleZipCallRecommenderMain.main(SingleZipCallRecommenderMain.java:18)
> 
> +++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Previously, there was no error after I included
> org.eclipse.recommenders.examples to the build path and also the files
> (like SingleZipCallRecommenderMain.java) run without any error (for
> the previous code base).
> 
>  This is the entry point for me to collect code completion result. I
> have tried multiple times but nothing changed. Could you please let me
> know how to fix the problem.

The Problem is that OSGi, which Code Recommenders is based on by virtue
of being an Eclipse plugin, has a more complex classpath model. Thus,
the examples can depend on Google Guava, version *14.0* even though some
older classes (10.0) are used by one of its libraries (the m2e Maven
runtime). Apparently, Eclipse puts the older version of Guava first on
the flat classpath a plain old "Java Application" uses.

The only workaround I have found (its quite ugly) is to manually add an
"External JAR" to your "Java Application's" Run Configuration:
$WORKSPACE/.metadata/.plugins/org.eclipse.pde.core/.bundle_pool/plugins/com.google.guava_14.0.1.v20130703-1129.jar

That JAR has to go before the "org.eclipse.recommenders.calls" entry.
Then Eclipse picks up the right version of Guava.

A proper solution would be to write a real OSGi application (see
org.eclipse.equinox.app.IApplication) rather than using the good old
"main" as entry point.

If you really want to go the public-static-void-main route, try running

  mvn dependency:build-classpath

below the org.eclipse.recommenders.calls project to get the flat
classpath of that project (and hope that you don't have to reorder it).

Hope that helps.

Andreas

[1] <https://bugs.eclipse.org/bugs/enter_bug.cgi?product=Recommenders>

-- 
Codetrails UG (haftungsbeschränkt)
The knowledge transfer company

Robert-Bosch-Str. 7, 64293 Darmstadt
Mobile: +49-170-811-3791
http://www.codetrails.com/

Managing Director: Dr. Marcel Bruch
Handelsregister: Darmstadt HRB 91940