Alternative IndexProvider dla Neo4J 1.9.1

Question

Używam Lucene 4 w mojej aplikacji i nie chcę tego zmieniać. Próbuję zintegrować Neo4J, która łączy Lucene 3.5 jako implementację IndexProvider, indeks neo4j-lucene.

Niestety, indeks neo4j-lucene nie działa, a przy tej zależności wykluczonej, aplikacja po prostu zawiesza się na czas nieokreślony podczas uruchamiania. Próbowałem wypróbować indeks neo4j-lucene4, ale wydaje się, że nie jest on utrzymywany bardzo dobrze i wymaga znacznej aktualizacji w celu pracy z Neo4J 1.9.1. Zmiany znacznie wykraczają poza moje rozumienie wewnętrznych elementów Neo4J.

Jednak widzę, że IndexProviders można podłączyć, więc mam nadzieję, że istnieje alternatywa dla Lucene - nie mogę jej jednak w tej chwili znaleźć. Czy ktoś może wskazać mi właściwy kierunek?

Wydaje się dziwne, że Lucene 4 jest od tak dawna, a Neo4J go nie obsługuje. Czy czegoś brakuje?

Obecnie mój POM wygląda to dla mojego Neo4J config:

<dependency> 
    <groupId>org.springframework.data</groupId> 
    <artifactId>spring-data-neo4j</artifactId> 
    <version>2.2.1.RELEASE</version> 
    <exclusions> 
     <exclusion> 
     <artifactId>neo4j</artifactId> 
     <groupId>org.neo4j</groupId> 
     </exclusion> 
     <exclusion> 
     <artifactId>neo4j-cypher</artifactId> 
     <groupId>org.neo4j</groupId> 
     </exclusion> 
    </exclusions> 
</dependency> 
<dependency> 
    <groupId>org.neo4j</groupId> 
    <artifactId>neo4j-kernel</artifactId> 
    <version>1.9.1</version> 
    <exclusion> 
     <groupId>org.neo4j</groupId> 
     <artifactId>neo4j-lucene-index</artifactId> 
    </exclusion> 
</dependency> 

<dependency> 
    <groupId>org.neo4j.app</groupId> 
    <artifactId>neo4j-server</artifactId> 
    <version>1.9.1</version> 
    <exclusions> 
     <exclusion> 
     <artifactId>neo4j</artifactId> 
     <groupId>org.neo4j</groupId> 
     </exclusion> 
     <exclusion> 
     <artifactId>neo4j-cypher</artifactId> 
     <groupId>org.neo4j</groupId> 
     </exclusion> 
     <exclusion> 
     <groupId>org.neo4j</groupId> 
     <artifactId>neo4j-lucene-index</artifactId> 
     </exclusion> 
    </exclusions> 
</dependency> 

    <!-- A temporary dependency until Neo4J builds in support for Lucene 4. 
    Looks like they're planning to incorporate this project anyway This project 
    is available on GitHub, and needs to be built with: mvn license:format mvn 
    install to install into your local repo. 
     <dependency> 
      <groupId>com.keatext</groupId> 
      <artifactId>neo4j-lucene4-index</artifactId> 
      <version>1.9.M01-SNAPSHOT</version> 
     </dependency>--> 

<dependency> 
    <groupId>org.hibernate</groupId> 
    <artifactId>hibernate-validator</artifactId> 
    <version>5.0.1.Final</version> 
</dependency> 

Answer 1

Odnotowano pewne zmiany wewnętrznie od 1,8 -> 1,9. W skrócie, dostawca indeks musi zarejestrować KernelExtensionFactory poprzez META-INF/usług, patrz https://github.com/neo4j/neo4j/blob/master/community/lucene-index/src/main/resources/META-INF/services/org.neo4j.kernel.extension.KernelExtensionFactory

Ten KernelExtensionFactory jest punktem wyjścia, tylko kasa wdrożenie w oparciu o Lucene 3 w https://github.com/neo4j/neo4j/tree/master/community/lucene-index.

Answer 2

Jeśli nie obchodzi cię, jaki indeks używa Neo4j, a używasz Mavena do zarządzania zależnościami, możesz użyć nazwy the Maven Shade plugin's class relocation feature, aby zmienić nazwę zależności Neene4j Lucene, aby nie kolidowała z innymi zależnościami w nowszych wersjach Lucene.

W moim przypadku wymagało to przeniesienia kodu zależnego od Neo4j do osobnego projektu Maven, ponieważ Shade od razu działa na całym projekcie/słoiku. Więc jeśli możesz uzyskać zależności od Lucene w różnych projektach, powinno to zadziałać dobrze.

Answer 3

Jakiś czas temu stanąłem przed tym problemem: pracowałem nad prototypowaniem i bardzo lubiłem tryb wbudowany Neo4j. Ale kiedy zdecydowałem się użyć Lucene 4 - natknąłem się na problem niezgodności.

OSGi

Jak tutaj zaproponowane: How to use two versions of jar in my java project - jeden z możliwych rozwiązań jest zastosowanie OSGi i owinąć Neo4j i Lucene 4 do różnych wiązek. Każdy pakiet będzie miał oddzielny moduł ładujący klasy - więc Neo4j będzie używać w klasach uruchamiania z Lucene 3, ale nadal będziesz mógł używać Lucene 4 do swoich celów.

Ale, o ile pracowałem nad prototypowaniem - nie chciałem poświęcać czasu na adaptację mojego projektu na platformę OSGi z powodu jednego powodu niekompatybilności dwóch komponentów.

Maven Shade Plugin

Tak, mam rozwiązany problem z pomocą Maven Shade Plugin.

Plugin Maven Shade umożliwia połączenie wszystkich zależności w pojedynczy "gruby" JAR (również zwany "uber JAR").

Można więc wygenerować "zależną od Neo4j" i używać jej w projekcie - zamiast "prawdziwej" zależności Neo4j.

Ale jest jeszcze jeden ważny moment: Lucene 3 i Lucene 4 mają tę samą strukturę pakietów, a wiele klas wciąż ma te same nazwy. Może to spowodować konflikty związane z ładowaniem klasy.

Aby rozwiązać ten problem, Maven Shade Plugin zapewnia zdolność do przenoszenia klas podczas generacji z „uber JAR”: http://maven.apache.org/plugins/maven-shade-plugin/examples/class-relocation.html

Można podać nazwę pakietu, a podczas pakowania - Shade Plugin ruszy klasy z określony pakiet i jego podpakiety do innej paczki, i będzie przepisał kod kodowy o kodzie.

więc podczas komponowania z "uber JAR" dla Neo4j - można skonfigurować Shade Plugin przenieść klasy Lucene 3 do innego pakietu, np:

org.apache.lucene.* -> shaded_3_6_2.org.apache.lucene.*

(Na szczęście wydaje się, że Neo4j nie używa refleksji, w zastosowaniu do rzeczy Lucene).

Tak, można utworzyć pusty projekt maven z następujących pom.xml:

<project 
    xmlns="http://maven.apache.org/POM/4.0.0" 
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
    xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> 
    <modelVersion>4.0.0</modelVersion> 

    <groupId>my.hack</groupId> 
    <artifactId>uber-neo4j</artifactId> 
    <version>1.9.3</version> 
    <packaging>jar</packaging> 
    <name>uber-neo4j</name> 

    <properties> 
     <neo4j-version>1.9.3</neo4j-version> 
    </properties> 

    <dependencies> 
     <dependency> 
      <groupId>org.neo4j</groupId> 
      <artifactId>neo4j</artifactId> 
      <version>${neo4j-version}</version> 
     </dependency> 
    </dependencies> 

    <build> 
     <plugins> 
      <plugin> 
       <groupId>org.apache.maven.plugins</groupId> 
       <artifactId>maven-shade-plugin</artifactId> 
       <version>2.3</version> 
       <executions> 
        <execution> 
         <phase>package</phase> 
         <goals> 
          <goal>shade</goal> 
         </goals> 
         <configuration> 
          <createDependencyReducedPom>false</createDependencyReducedPom> 
          <relocations> 
           <relocation> 
            <pattern>org.apache.lucene</pattern> 
            <shadedPattern>shaded_lucene_3_6_2.org.apache.lucene</shadedPattern> 
           </relocation> 
          </relocations> 
         </configuration> 
        </execution> 
       </executions> 
      </plugin> 
     </plugins> 
    </build> 

    <repositories> 
     <repository> 
      <id>neo4j-repo</id> 
      <name>Neo4j Repository</name> 
      <url>http://m2.neo4j.org/content/repositories/releases</url> 
     </repository> 
    </repositories> 
</project> 

opisanej konfiguracji - zapewnia zdolność do generowania "uber JAR" dla Neo4j ze zmienionymi nazwami pakietów Lucene 3 (tylko zrobić mvn install) .

I na koniec można dołączyć te elementy jako moduł do swojego projektu maven.

Po obejściu tego problemu będziesz mógł używać zarówno Neo4j, jak i Lucene 4 w swoim projekcie.

wszelki wypadek, oto link GitHub repozytorium z konfiguracji maven dla pokolenia „uber JAR” dla Neo4j: https://github.com/lagodiuk/neo4j-uber-jar