recommenders / rival

RiVal recommender system evaluation toolkit
rival.recommenders.net
Apache License 2.0
150 stars 40 forks source link

Type mismatch: cannot convert from CSVParser to Iterable<CSVRecord> #125

Open 8-chems opened 7 years ago

8-chems commented 7 years ago

Hi, I am using Eclipse as a development environment , in the class UIPParser I am not able to resolve the error above even with all tested common-csv jar files, the lines are ; if (isHasHeader()) { records = CSVFormat.EXCEL.withDelimiter(getDelimiter()).withHeader().parse(in); } else { records = CSVFormat.EXCEL.withDelimiter(getDelimiter()).parse(in); } (51 and 53)

alansaid commented 7 years ago

Hi @ChemsEddineBerbegue, Can you provide a minimal working example (or not working in this case)? I believe this is likely to an incorrect maven setup in your Eclipse environment as both CVSParser and CSVRecord classes are from a third party module.

8-chems commented 7 years ago

Hi, this is the class which make the problem: import org.apache.commons.csv.CSVFormat; i tried with many versions of commons-csv (1.0 1.1 1.2 1.4) but all of them haven't solved the problem, in addition I am using mahout version 0.12.2 and lenskit 2.2.1, all classes are right except the problem in the class UIPParser. the method .parse(in) returns a CSVparser while the variable "record" have the type Iterable. pom.xml file located in the project rival core indicates that the used version of commons-csv is 1.0.

alansaid commented 7 years ago

Can you provide a code example (of your code) and the scenario in which your build fails? As you can see in the rival-core pom file, RiVal uses Apache Commons CSV 1.0. How are you using RiVal? The base case is that you import RiVal through the pom file in your Maven-built project.

8-chems commented 7 years ago

HI, I never worked with Maven before, I took all the separated projects and merge them in just one SRC folder than put them in eclipse project adding the required jar files and it is done, I used to work with similar projects with the similar approache it worked fine except rival.

abellogin commented 7 years ago

Hi @ChemsEddineBerbegue, since that is not the expected development scenario, it is not easy for us to reproduce your problem. I could take a look at it if you provide us with a link to your environment (e.g., a dropbox link or a ZIP file). In any case, according to the documentation of the commons-csv library that @alansaid pointed out before, that method should always work. See here the code included in the documentation is the same as the one in the UIPParser. Hence, I would encourage you to check if you are really including the commons-csv library and if there no other conflicts with other libraries that might be imported with higher preference in your Eclipse project.

Best, Alejandro

alansaid commented 7 years ago

I suggest you try importing it as a Maven project and use Maven to build it. This simply appears to be an artefact of attempting to build RiVal in an unsupported way (at least by us).

To see how to use RiVal as a Maven dependency, please have a look at the rival-examples sub-project

8-chems commented 7 years ago

I am agree that there is certainly a conflict with the rest of jar files, thank you

abellogin commented 7 years ago

Hi @ChemsEddineBerbegue ,

I faced recently this problem you issued some time ago and found a solution using Maven.

The thing is that there is a conflict with the artifact solr-commons-csv from mahour which, in my build, was producing the same error as the one you reported (mainly due to that artifact importing a different version of the commons-csv module). The fix was done by modifying the pom as follows:

    <dependency>
        <groupId>org.apache.mahout</groupId>
        <artifactId>mahout-mr</artifactId>
        <version>0.10.0</version>
        <exclusions>
            <exclusion>
                <groupId>org.apache.solr</groupId>
                <artifactId>solr-commons-csv</artifactId>
            </exclusion>
        </exclusions>
    </dependency>

Hope this helps.

abellogin commented 7 years ago

Btw, @alansaid, if we check that this solution does not break any of the mahout code, we should add it to the release ASAP.

alansaid commented 7 years ago

Odd that it wasn't causing errors before. Let's go ahead with the update. However, given Mahout's current development direction, we could consider skipping Mahout in future releases. Mahout Taste is becoming deprecated (or at least stale with only minor bugfixes coming in in the last ~2 years, see inline screenshot of latest commits in https://github.com/apache/mahout/tree/master/mr/src/main/java/org/apache/mahout/cf/taste/impl/recommender) image

alansaid commented 7 years ago

What's the status current status of this?