Skip to content
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

Open
aleksanderlech opened this issue Oct 6, 2021 · 5 comments
Open

Extract API classes to a separate artifact #2397

aleksanderlech opened this issue Oct 6, 2021 · 5 comments
Assignees
Labels
status: feedback-provided Feedback has been provided

Comments

@aleksanderlech
Copy link

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.

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Oct 6, 2021
@meistermeier
Copy link
Collaborator

I wonder which ogm-annotations jar you are referring to. There is nothing I am aware of.
All the dependencies are defined in the ogm-core library. This library does also contain all the mapping code etc.

@meistermeier meistermeier added status: waiting-for-feedback We need additional information before we can continue and removed status: waiting-for-triage An issue we've not yet triaged labels Oct 8, 2021
@meistermeier meistermeier self-assigned this Oct 8, 2021
@spring-projects-issues
Copy link

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.

@spring-projects-issues spring-projects-issues added the status: feedback-reminder We've sent a reminder that we need additional information before we can continue label Oct 15, 2021
@aleksanderlech
Copy link
Author

aleksanderlech commented Oct 21, 2021

I wonder which ogm-annotations jar you are referring to. There is nothing I am aware of. All the dependencies are defined in the ogm-core library. This library does also contain all the mapping code etc.

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.
Therefore it could be even better if to create a small module containing only the annotation classes.

@spring-projects-issues spring-projects-issues added status: feedback-provided Feedback has been provided and removed status: waiting-for-feedback We need additional information before we can continue status: feedback-reminder We've sent a reminder that we need additional information before we can continue labels Oct 21, 2021
@michael-simons
Copy link
Collaborator

I wouldn't mind extracting a separate module in this project too much. What stands against it is the fact our @Node, @Id and some other annotations are meta-annotated with Spring Data commons one, so it wouldn't gain too much.

@aleksanderlech
Copy link
Author

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.
I think that one of the good examples to follow are Jackson library as well as Java Validation API. Both are meant to be used with some POJOs and both of them keep their API separated from the implementation.
I won't be insisting on this change to happen soon but at least leave a thought for the future and let you guys decide.

Have a great weekend :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
status: feedback-provided Feedback has been provided
Projects
None yet
Development

No branches or pull requests

4 participants