Re: Terms clarification and modules splitting logic

Alexey, Thanks for the detailed explanation. Ok, let's agree on having the internal package. I've created the ticket [1] to unify it's usage within the project. [1] https://issues.apache.org/jira/browse/IGNITE-14506 чт, 8 апр. 2021 г. в 15:34, Alexey Goncharuk : > Alexei, > > The main benefit

Re: Terms clarification and modules splitting logic

Alexei, The main benefit from Jigsaw that I see for the project structure is controllable module interaction. Let's take our networking module as an example first. We may want to make sure that module implementation specifics do not leak to outside modules, so we define in the module definition t

Re: Terms clarification and modules splitting logic

Alexey, Can you provide us some details on jygsaw adoption to better understand the benefits ? "We should be free to change them without any compatibility contract" - let's mark such classes with a special annotation like @Internal, will it work for you ? ср, 31 мар. 2021 г. в 15:10, Alexey Go

Re: Terms clarification and modules splitting logic

This won't work with the Java Jigsaw module system because it prohibits having two identical packages in different modules. I really hope that we will adopt Jigsaw in the near future. Unless you are suggesting moving all utility classes under org.apache.ignite.api.util package, bit this looks reall

Re: Terms clarification and modules splitting logic

Alexey, I would instead suggest moving the public utility classes to org.apache.ignite.api. package in the util module to separate them from internal classes, if we really need this. Actually, I don't think there is a point in separating public/internal classes in the util module. What are the b

Re: Terms clarification and modules splitting logic

Alexei, I had the same opinion regarding the internal package, but we still need to somehow distinguish between public and internal classes in the ignite-util module. If we introduce the internal package in the util, we should follow the same structure in other modules. Thoughts? вт, 30 мар. 202

Re: Terms clarification and modules splitting logic

+1 to package and module naming. +1 to service definition as "component providing a high-level API to user/other components/services" I would avoid defining strict rules for Manager and Processor. For me it just adds confusion without real value. A component can be a Manager if it manages somethin

Re: Terms clarification and modules splitting logic

Agree with package and module naming. I just thought that Service is a self-suffucient component and provides high-level API to user/other components/services (e.g. RaftService to TableService). Manager is internal component - a logical brick of the Service (e.g. RaftGroupManager or TableSchemaMan

Re: Terms clarification and modules splitting logic

Hello Alexander, Igniters, I support the suggestion, we need to work out some ground rules to have a consistent naming convention. Agree with having at most one component per project module - this requirement may turn out to be too strict in the future, but now it seems reasonable and may help us

Terms clarification and modules splitting logic

Igniters, Seems that within Ignite-3 we have some mess in terms like manager, cpu, service, module, etc. Let's clarify this point. Also It'll be great to discuss the rules of dividing code into modules. I'll use the context of Ignite cluster & node lifecycle