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

Let sdk and sdk-reactor reuse common code #3

Open
seeflood opened this issue Dec 6, 2021 · 8 comments
Open

Let sdk and sdk-reactor reuse common code #3

seeflood opened this issue Dec 6, 2021 · 8 comments

Comments

@seeflood
Copy link
Member

seeflood commented Dec 6, 2021

Let sdk and sdk-reactor reuse common code and reduce redundencies.

See mosn/layotto#349 (comment)

@kevinten10
Copy link

Can I put the entity class in the common part first?

@seeflood
Copy link
Member Author

seeflood commented Dec 8, 2021

@kevinten10 Do you mean the request and response object under the domain package?
image
Sure !
Since the domain objects in spec/sdk/runtime/v1/domain have already been used by users(except the lock related objects,e.g. TryLockRequest ),please keep them compatible when refactoring the code.
For example,we should keep the existing fields and package name of the objects in spec/sdk/runtime/v1/domain not changed after moving them into a new module. Of course , we can add new fields in them.

@seeflood
Copy link
Member Author

seeflood commented Dec 8, 2021

image

kevinten10 added a commit to kevinten10/java-sdk-1 that referenced this issue Dec 8, 2021
@kevinten10
Copy link

Yes, I will keep the unchanged of sdk-runtime.

I plan to move all the definitions of all Entity and Runtime interfaces to the sdk-domain module, which will be consistent with the current sdk-runtime module, and then the sdk-reactor module also uses these definitions.

Then define the RxRuntime interface Extends Runtime interface and add Reactor's API implementation.

At the same time, the sdk-domain will use reactor-core with compile scope, which will not affect users who use non-reactor sdk.

At present, I am doing these work.

@seeflood
Copy link
Member Author

seeflood commented Dec 12, 2021

@kevinten10 Thanks for your details!
I try to draw a picture to illustrate your design:
image
Is my understanding correct?

At the same time, the sdk-domain will use reactor-core with compile scope, which will not affect users who use non-reactor sdk.

I didn't understand.From my understanding, if we configurate the maven dependency to be compile scope, users who use non-reactor sdk will also be affected. Could you give more details?

@kevinten10
Copy link

Give me some time for me to try, how can the dependencies in the SDK not propagate to the dependencies of the application

@seeflood
Copy link
Member Author

seeflood commented Dec 13, 2021

image
@kevinten10 Maybe this way? Extract the common domain objects into a new module and leave those not common in their own module

@kevinten10
Copy link

All right! I will refactor it in #7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants