You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@seata.apache.org by yixia <yi...@apache.org> on 2024/01/06 14:53:55 UTC

[discuss] Apache Seata (incubating) samples code specification

Greetings all!

The specifications of different modules in the seata samples project are
inconsistent.

For example:

1. pom: some modules depend on the top of seata-samples, some have their
own dependencies, which are prone to conflicts.

2. naming: some module names are unclear, such as dubbo and etcd3. users
cannot understand the meaning of the project from the naming.


Therefore, we need to define a set of specifications for the code of seata
samples.

*# Directory Structure*

The first and second levels are more of a directory

Top level: seata-samples

Second layer: at-sample, tcc-sample, saga-sample, xa-sample

Third floor, The third layer is the specific sample and the naming
convention is as follows:

*# naming*

naming with framework: spring-nacos-seata, springboot-naocs-zk-seata ...

*# dependency*

pom: The dependencies of each sample should be independent and should not
depend on the dependencies of the parent pom of seata samples.


You can leave your comments or vote whether you agree with this suggestion.

Re: [discuss] Apache Seata (incubating) samples code specification

Posted by 尹祥琨 <pt...@outlook.com>.
I believe it will make seata-samples better structured and easier to evolve. Standard matters.

Best regards,
Xiangkun Yin

> 2024年1月7日 23:29,Min Ji <ji...@apache.org> 写道:
> 
> I think it is a very good suggestion. In the past, many people have
> contributed to seata-sample, but the lack of unified standards has led to
> poor readability of the code and even some that cannot run normally. I
> would like to add a suggestion that for code examples targeting
> cross-service calls, try to maintain a unified business scenario as much as
> possible.
> 
> 
> Warm regards,
> 
> Ji Min
> 
> 
> yixia <yi...@apache.org> 于2024年1月6日周六 22:54写道:
> 
>> Greetings all!
>> 
>> The specifications of different modules in the seata samples project are
>> inconsistent.
>> 
>> For example:
>> 
>> 1. pom: some modules depend on the top of seata-samples, some have their
>> own dependencies, which are prone to conflicts.
>> 
>> 2. naming: some module names are unclear, such as dubbo and etcd3. users
>> cannot understand the meaning of the project from the naming.
>> 
>> 
>> Therefore, we need to define a set of specifications for the code of seata
>> samples.
>> 
>> *# Directory Structure*
>> 
>> The first and second levels are more of a directory
>> 
>> Top level: seata-samples
>> 
>> Second layer: at-sample, tcc-sample, saga-sample, xa-sample
>> 
>> Third floor, The third layer is the specific sample and the naming
>> convention is as follows:
>> 
>> *# naming*
>> 
>> naming with framework: spring-nacos-seata, springboot-naocs-zk-seata ...
>> 
>> *# dependency*
>> 
>> pom: The dependencies of each sample should be independent and should not
>> depend on the dependencies of the parent pom of seata samples.
>> 
>> 
>> You can leave your comments or vote whether you agree with this suggestion.
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@seata.apache.org
For additional commands, e-mail: dev-help@seata.apache.org


Re: [discuss] Apache Seata (incubating) samples code specification

Posted by Min Ji <ji...@apache.org>.
I think it is a very good suggestion. In the past, many people have
contributed to seata-sample, but the lack of unified standards has led to
poor readability of the code and even some that cannot run normally. I
would like to add a suggestion that for code examples targeting
cross-service calls, try to maintain a unified business scenario as much as
possible.


Warm regards,

Ji Min


yixia <yi...@apache.org> 于2024年1月6日周六 22:54写道:

> Greetings all!
>
> The specifications of different modules in the seata samples project are
> inconsistent.
>
> For example:
>
> 1. pom: some modules depend on the top of seata-samples, some have their
> own dependencies, which are prone to conflicts.
>
> 2. naming: some module names are unclear, such as dubbo and etcd3. users
> cannot understand the meaning of the project from the naming.
>
>
> Therefore, we need to define a set of specifications for the code of seata
> samples.
>
> *# Directory Structure*
>
> The first and second levels are more of a directory
>
> Top level: seata-samples
>
> Second layer: at-sample, tcc-sample, saga-sample, xa-sample
>
> Third floor, The third layer is the specific sample and the naming
> convention is as follows:
>
> *# naming*
>
> naming with framework: spring-nacos-seata, springboot-naocs-zk-seata ...
>
> *# dependency*
>
> pom: The dependencies of each sample should be independent and should not
> depend on the dependencies of the parent pom of seata samples.
>
>
> You can leave your comments or vote whether you agree with this suggestion.
>