New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Extract API classes to a separate artifact #2397
Comments
I wonder which ogm-annotations jar you are referring to. There is nothing I am aware of. |
If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed. |
I am sorry for the late response. You were right, that was the ogm-core but still at least not the whole spring module and its dependencies. |
I wouldn't mind extracting a separate module in this project too much. What stands against it is the fact our |
Hello Michael! I understand but still think that it would be a step towards a good direction. I hope that in the future spring-data-commons considers the same step as I can imagine even more people having similar struggles there. Have a great weekend :) |
Hello again,
In the previous version of spring-data-neo4j we had a possibility to add the ogm-annotations jar as a dependency and therefore create a shared Neo4j entities artifact.
In our scenario we have a service that writes to Neo4j and another one that only reads the modes. In such situation it makes sense to have a shared jar with neo4j model entities.
Since the 6.x changes the mapping annotations are no longer a separate artifact which forces us to include the whole spring-data-neo4j dependency:
dependencies { api 'org.springframework.data:spring-data-neo4j:6.1.5' }
We really would like to avoid that. Therefore I ask you guys whether its possible to extract the annotations/api related classes into a separate artifact. Especially the annotation classes residing in
/org/springframework/data/neo4j/core/schema
.It would be also nice from the design perspective since the API does not change so often like the implementation does. Its nice to keep it separated.
The text was updated successfully, but these errors were encountered: