Ilya,
I think common sense is our only friend here :) The low number of
dependencies is indeed one of the advantages of Ignite. On the other hand,
the "zero dependency" approach we've been trying to follow for the last
several years sometimes forces us to implement, stabilize and maintain a
whole
Hello!
I think it is a strong side of Apache Ignite that it has a low number of
JARs and minimal dependencies. It may be less relevant now than 10 years
ago, but it's still a plus.
Not sure how fast it would evaporate as the number of JARs and dependencies
grows.
Regards,
--
Ilya Kasnacheev
ч
Ilya, it is a good point about jar name. If it really unresolvable problem we
should leave modules name as is(I do not insist on renaming it was just a
proposal)
I also not really got you point about 'zillion JARs'. Do you think it will be a
problem if the number of JARs increases a little? If
Hello!
When you do mvn dependencies:copy, you will now end up with
"ignite-core-X.Y.Z.jar", "ignite-indexing-X.Y.Z.jar"
But if we remove "ignite" from artifact name, user will end up with cryptic
"configuration.jar", "raft.jar", etc, etc.
Remember that group name is discarded in file names. There
> Nikolay, maybe is it better to discuss your question on a separate topic?
> Because looks like it is a pretty discussable topic.
Sorry for interrupting original discussion.
For me it was a overlapping topic in the beginning.
Agree that we we should have separate thread.
> 9 дек. 2020 г., в 1
Hello,
I totally agree that we should start to think about the module organization.
I suggest making the new confluence page where we define new rules on how to
develop modules.
In my opinion, at least, the following topics should be covered there(it makes
sense to discuss every topic separate
Hello, Zhenya, Ivan.
> Hello Nikolay, if i find out introduced features structure in some project, i
> would prefer to choose different one )
Many, of the real world users disagree with you.
Please, take a look at some examples from widely used projects:
Kafka -
https://github.com/apache/kafka
+1 to Alexey's ideas.
As for annotations, I actually can see the difference between Expirimental
and NonStable. The latter means that a feature works, but its API can still
be changed (in other words, no backwards compatibility guarantees). The
former is just something that is under development, c
+1 for modules
08.12.2020, 16:02, "Andrey Gura" :
> Definitely agree with Alexey. Separating API declaration from
> implementation could really improve system design and avoid coupling.
>
> About extending @IgniteExperimental annotation. It doesn't look good
> to me. We should consider any API eit
Definitely agree with Alexey. Separating API declaration from
implementation could really improve system design and avoid coupling.
About extending @IgniteExperimental annotation. It doesn't look good
to me. We should consider any API either experimental or stable. Third
option is deprecated API.
Hello, Alexey.
Think we can extend our @IgniteExperimental annotation.
`@IgniteExperimental` - mark features that are truly experimental and can be
completely removed in future releases.
`@NotRecommended` - mark features that widely adopted by the users but
implemented wrong or have known issue
11 matches
Mail list logo
