Replies: 7 comments 1 reply
-
|
#4418 is a pull request to introduce the spring cloud apollo client, which is an example that we could use to create as a standalone repository. |
Beta Was this translation helpful? Give feedback.
-
|
I think apollo-core is just a module project, it doesn't have any direct user scenarios, so its not standalone project and therefore repository, maybe it's an an part of apollo server, or duplicated in other projects. Am I right?
发自我的iPhone
… 在 2022年6月25日，18:43，Jason Song ***@***.***> 写道：
#4418 is a pull request to introduce the spring cloud apollo client, which is an example that we could use to create as a standalone repository.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
|
Beta Was this translation helpful? Give feedback.
-
|
I agree it. It will be more cleaner. Currently, there are few changes in apollo-core, and the apollo-client delivery relies on apollo-core. So user's application will directly rely on apollo-core. So it seems more appropriate to put the apollo-core and the apollo-client together. Keep apollo-core and apollo-client has the same version will be more friendly to users. Then, Apollo server relies on the apollo-core jar package.
I thank it's may not a good idea. |
Beta Was this translation helpful? Give feedback.
-
|
It seems that apollo-core use in multiple modules. When run for module in $(find . -maxdepth 1 -name "apollo*" -type d); do
echo "${module}"
filenames=$(find ${module} -name "*.java" -type f)
if [ -n "${filenames}" ]; then
echo "${filenames}" | xargs grep -h "import com.ctrip.framework.apollo.core" | sort -u
echo ""
fi
donein the repo, I found some usage of apollo-core in other modules Whatever the module changed or moved, there is always a common module How we deal with this common module Or there is another better way to handle it? |
Beta Was this translation helpful? Give feedback.
-
|
apollo's client will be integration with multiple runtime, like
Is it better split the integration solution to differect maven module? For example, if user's runtime is raw jdk, user only use raw jdk's maven dependency without care about the spring. if user's runtime is spring cloud, user choose spring cloud's maven dependency. shortcoming: user maybe don't know how to choose a dependency because there are multiple dependency. |
Beta Was this translation helpful? Give feedback.
-
Since it's only a common module hosting some libs, it's not suitable to split it as a standalone repository. I think it's better to host it with
Currently
Apollo also has some other client libraries like
Or if we host them as different maven modules in one repository like
Given the future maintenance cost consideration, I think hosting them as different maven modules in one repository might be better. What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
I submitted a pr #4440 to move
|
Beta Was this translation helpful? Give feedback.
-
|
I submitted a pr #4594 to move
|
Beta Was this translation helpful? Give feedback.
-
Currently, the main repository contains many modules. Hence, its releasing process is complex and takes a long time to release, which could be a problem in some situations. For example, if there is a bug in apollo-client and we need to release a patch to fix it, currently we have to also release all the apollo server packages and docker images.
My proposal is to keep the main repository only contain apollo server packages and move other modules to be standalone repositories under apolloconfig.
The details are as below:
With these structural changes, the main repository will look cleaner and each standalone repository could have its own releasing process and schedule.
There may be situations that some feature might introduce changes to multiple repositories which involves extra effort, but I think it's acceptable as these cases are rare.
Please feel free to share your ideas.
Beta Was this translation helpful? Give feedback.
All reactions