The integration with Neo4j in OGM makes it possible for a user to select the strategy that he wants to use to connect to an embedded or remote Neo4j instance. There are 3 possible options: 1) Embedded mode, Neo4j run in the same JVM 2) Remote via HTTP interface using RestEasy 3) Remote via the Bolt protocol using the neo4j-java-driver library Everything is now in one single artifact meaning that for each case we have more dependencies than needed, in particular for the remote cases. Possible solutions I can think of at the moment are: 1) Have different maven artifacts: - We could have 3 artifacts: EMBEDDED, HTTP and BOLT - or 2 artifacts: EMBEDDED and REMOTE: This won't completely solve the issue because w would still have resteasy (for HTTP) and neo4j-java-driver (for BOLT) but it might be a good trade-off We will need to share some resource so this approach might require a Neo4j common library. 2) Make some dependencies optional (Need to test this, but it might work) 3) Use some maven plugin to generate different artifacts from the same module. I haven't used this approach before so I'm not sure if it is feasible. 4) ??? Any opinion about this? Issue on JIRA: https://hibernate.atlassian.net/browse/OGM-1190 Thanks, Davide _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

On 19 October 2016 at 10:44, Yoann Rodiere <yoann(a)hibernate.org&gt; wrote: > Is there any particular reason why we would not want to create three > artifacts, besides backward compatibility? It seems the obvious and ideal > solution, but I might be missing something. > > If there is common code, we can always create a fourth -neo4j-core artifact > that would have no interest to users but would simply ensure we don't > duplicate code, and would be delivered through transitive dependencies. > > About backward compatibility, I guess there are two options: > > - If the last released version of the artifact used to contain only the > embedded mode, we can use maven relocation > - Otherwise, we can advertise this artifact as deprecated, remove almost > everything in it and add the relevant new artifacts as dependencies. > > Or am I being too naive? Seems very reasonable. Maybe I'm naive too :) -- Sanne > > Yoann Rodière <yoann(a)hibernate.org&gt; > Hibernate NoORM Team > > On 19 October 2016 at 11:17, Davide D'Alto <davide(a)hibernate.org&gt; wrote: > >> The integration with Neo4j in OGM makes it possible for a user to >> select the strategy that he wants to use to connect to an embedded or >> remote Neo4j instance. >> There are 3 possible options: >> 1) Embedded mode, Neo4j run in the same JVM >> 2) Remote via HTTP interface using RestEasy >> 3) Remote via the Bolt protocol using the neo4j-java-driver library >> >> Everything is now in one single artifact meaning that for each case we >> have more dependencies than needed, in particular for the remote >> cases. >> >> Possible solutions I can think of at the moment are: >> >> 1) Have different maven artifacts: >> - We could have 3 artifacts: EMBEDDED, HTTP and BOLT >> - or 2 artifacts: EMBEDDED and REMOTE: This won't completely solve >> the issue because w would still have >> resteasy (for HTTP) and neo4j-java-driver (for BOLT) but it >> might be a good trade-off >> >> We will need to share some resource so this approach might require >> a Neo4j common library. >> >> 2) Make some dependencies optional (Need to test this, but it might work) >> >> 3) Use some maven plugin to generate different artifacts from the same >> module. I haven't used this approach before so I'm not sure if it is >> feasible. >> >> 4) ??? >> >> Any opinion about this? >> >> Issue on JIRA: https://hibernate.atlassian.net/browse/OGM-1190 >> >> Thanks, >> Davide >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev

I always prefer to migrate early to the right solution when there is a compelling reason to do so and a clear logic in it.