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
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
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
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
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
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
+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
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
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
