I would prefer to see these modules split as 3 different Maven
modules, but I wouldn't personally consider such work a priority.
Splitting them up would make for "lighter" fragments for e.g. Swarm,
but at the cost of a couple more paragraphs of documentation which
needs to be understood (more complex).
So I dislike the 2-modules tradeoff as users would be faced with the
additional configuration complexity, yet they would only get a
half-baked reward in exchange for it.
If you find some "interesting" Maven plugin which allows some kind of
build-time reorganization of these dependencies then please make sure
that we actually test the consumption of the output maven definitions.
In other words, I'd avoid that!
Thanks,
Sanne
On 19 October 2016 at 10:17, Davide D'Alto <davide(a)hibernate.org> 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