Re: [DISCUSSION] Ignite.C++ and CMake

[Pavel Tupitsyn]

Ivan,

Thank you for such a detailed explanation!
I am sorry if I upset you.

I just wanted to make sure that instructions are correct,
and I simply missed those 2 dots. Now it all works perfectly.

Pavel

On Wed, Jul 1, 2020 at 8:09 AM Ivan Daschinsky  wrote:

> Let me explain with details.
>
> CMake is unusual from other build systems, that it can separate build root
> and source root. Moreover, it is strongly discouraged to mix them.
> Benefits:
> 1. You can have many build with different options using same source.
> 2. You can build project with different toolchain using same source.
> 3. You can build project for different platforms using same source
> (cross-compilation, docker, etc.)
>
> Common patter is:
> 1. Create build root.
> 2. Change current dir to build root.
> 3. Invoke cmake in build root, pointing to source root.
>
> Usually build root is subdirectory, of source root. So, as it mentioned in
> DEVNOTES.txt, usual steps are:
> 1. mdkir  (usually named cmake-build-[-]
> 2. cd 
> 3. cmake [-DOPTION1=VALUE1 -DOPTION2=VALUE2 ... ] .. (NB! This double dots
> are important, they points to source root)
>
> This is so common, that you can hardly find any tutorial about CMake in
> google without thes double dots. This is basic of CMake.
>
> So if you think that we should explain for C++ developers basics of the
> most common build system (CMake is really very popular and nowadays usually
> must for new projects),
> we can add this to DEVNOTES.txt. But I think that is not necessary at all.
> For example, we don't explain basics of maven, though it is not obvious at
> all as it seems to us, Ignite developers.
>
> ср, 1 июл. 2020 г. в 06:18, Ivan Daschinsky :
>
> > Pavel, pay attention to two dots at the end. All build files should stay
> > at current dir, and cmake-build-release is supposed to be a build root.
> And
> > this directory is added to gitignore. Actually, build directory can be
> > everywhere, but you should pass path to dir, that contains root
> > CMakeLists.txt. Usually it is parent directory of cmake-build-release, so
> > double dot is used. It is so common pattern of usage and I simply cannot
> > understand why it is misleading.
> >
> > ср, 1 июл. 2020 г., 0:48 Pavel Tupitsyn :
> >
> >> This is awesome, thanks everyone!
> >>
> >> I've tried following the instructions, and the following two steps seem
> to
> >> be misleading:
> >> * mkdir cmake-build-[release|debug]
> >> * cd ./cmake-build-[release|debug]
> >>
> >> When I run cmake in the newly created cmake-build-debug dir, I get:
> >> CMake Error: The source directory
> >> "/home/pavel/w/ignite/modules/platforms/cpp/cmake-build-release" does
> not
> >> appear to contain CMakeLists.txt.
> >>
> >> If I skip those 2 steps, I can build Ignite C++ and run tests with ctest
> >> on
> >> Ubuntu 20.04.
> >>
> >>
> >> Another observation: building the project produces untracked git files.
> >> Should we update gitignore accordingly?
> >>
> >>
> >> Thanks,
> >> Pavel
> >>
> >>
> >> On Tue, Jun 30, 2020 at 9:33 PM Ivan Daschinsky 
> >> wrote:
> >>
> >> > Ok, CMake now is the only option to build C++ on non-windows
> platforms.
> >> > Autotools is removed from master.
> >> >
> >> > Many thanks to Igor Sapego, Zhenya Stanilovsky, Nickolay Izhikov and
> >> Ilya
> >> > Kasnacheev for review, testing and suggestions.
> >> >
> >> > вт, 23 июн. 2020 г. в 18:42, Ivan Daschinsky :
> >> >
> >> > > I suppose, that removal of autotools from source code is a question
> >> of a
> >> > > week. There is no need to support it.
> >> > >
> >> > > вт, 23 июн. 2020 г., 18:38 Ilya Kasnacheev <
> ilya.kasnach...@gmail.com
> >> >:
> >> > >
> >> > >> Hello!
> >> > >>
> >> > >> Once you do that, I think it would make sense to remove autotools
> >> > >> invocation from artifact build process. In the future we may choose
> >> to
> >> > >> remove autotools support entirely.
> >> > >>
> >> > >> Regards,
> >> > >> --
> >> > >> Ilya Kasnacheev
> >> > >>
> >> > >>
> >> > >> вт, 23 июн. 2020 г. в 18:00, Petr Ivanov :
> >> > >>
> >> > >> > That host was down for some time and got up only recently.
> >> > >> > Installed cmake there also.
> >> > >> >
> >> > >> >
> >> > >> >
> >> > >> > > On 23 Jun 2020, at 17:39, Ivan Daschinsky  >
> >> > >> wrote:
> >> > >> > >
> >> > >> > > Petr, I see, that cmake is missing on aitc10_05 but it is in
> pool
> >> > and
> >> > >> > > trying to run build.
> >> > >> > >
> >> > >> > > [1] --
> >> > >> > >
> >> > >> >
> >> > >>
> >> >
> >>
> https://ci.ignite.apache.org/buildConfiguration/IgniteTests24Java8_PlatformCPPCMakeLinux/5412025
> >> > >> > >
> >> > >> > > вт, 23 июн. 2020 г. в 17:33, Ivan Daschinsky <
> >> ivanda...@gmail.com>:
> >> > >> > >
> >> > >> >  For the sake of discretion, I'd purpose to remove old suites
> >> from
> >> > >> Run
> >> > >> > >> All and archive or pause them for some time before removal.
> >> > >> > >> Agree, I was talking about removal from RunAll chain, complete
> >> > >> removal
> >> > >> > is
> >> > >> > >> not n

Re: [DISCUSSION] Ignite.C++ and CMake

[Ivan Daschinsky]

No, I am really curious if this instruction complete or not. Actually, Ilya
Kasnacheev asked me about the same thing as you. And may be instruction is
not so obvious and should be reworked. You know, that developers are not
usually great in writing documentation.

ср, 1 июл. 2020 г., 10:37 Pavel Tupitsyn :

> Ivan,
>
> Thank you for such a detailed explanation!
> I am sorry if I upset you.
>
> I just wanted to make sure that instructions are correct,
> and I simply missed those 2 dots. Now it all works perfectly.
>
> Pavel
>
> On Wed, Jul 1, 2020 at 8:09 AM Ivan Daschinsky 
> wrote:
>
> > Let me explain with details.
> >
> > CMake is unusual from other build systems, that it can separate build
> root
> > and source root. Moreover, it is strongly discouraged to mix them.
> > Benefits:
> > 1. You can have many build with different options using same source.
> > 2. You can build project with different toolchain using same source.
> > 3. You can build project for different platforms using same source
> > (cross-compilation, docker, etc.)
> >
> > Common patter is:
> > 1. Create build root.
> > 2. Change current dir to build root.
> > 3. Invoke cmake in build root, pointing to source root.
> >
> > Usually build root is subdirectory, of source root. So, as it mentioned
> in
> > DEVNOTES.txt, usual steps are:
> > 1. mdkir  (usually named
> cmake-build-[-]
> > 2. cd 
> > 3. cmake [-DOPTION1=VALUE1 -DOPTION2=VALUE2 ... ] .. (NB! This double
> dots
> > are important, they points to source root)
> >
> > This is so common, that you can hardly find any tutorial about CMake in
> > google without thes double dots. This is basic of CMake.
> >
> > So if you think that we should explain for C++ developers basics of the
> > most common build system (CMake is really very popular and nowadays
> usually
> > must for new projects),
> > we can add this to DEVNOTES.txt. But I think that is not necessary at
> all.
> > For example, we don't explain basics of maven, though it is not obvious
> at
> > all as it seems to us, Ignite developers.
> >
> > ср, 1 июл. 2020 г. в 06:18, Ivan Daschinsky :
> >
> > > Pavel, pay attention to two dots at the end. All build files should
> stay
> > > at current dir, and cmake-build-release is supposed to be a build root.
> > And
> > > this directory is added to gitignore. Actually, build directory can be
> > > everywhere, but you should pass path to dir, that contains root
> > > CMakeLists.txt. Usually it is parent directory of cmake-build-release,
> so
> > > double dot is used. It is so common pattern of usage and I simply
> cannot
> > > understand why it is misleading.
> > >
> > > ср, 1 июл. 2020 г., 0:48 Pavel Tupitsyn :
> > >
> > >> This is awesome, thanks everyone!
> > >>
> > >> I've tried following the instructions, and the following two steps
> seem
> > to
> > >> be misleading:
> > >> * mkdir cmake-build-[release|debug]
> > >> * cd ./cmake-build-[release|debug]
> > >>
> > >> When I run cmake in the newly created cmake-build-debug dir, I get:
> > >> CMake Error: The source directory
> > >> "/home/pavel/w/ignite/modules/platforms/cpp/cmake-build-release" does
> > not
> > >> appear to contain CMakeLists.txt.
> > >>
> > >> If I skip those 2 steps, I can build Ignite C++ and run tests with
> ctest
> > >> on
> > >> Ubuntu 20.04.
> > >>
> > >>
> > >> Another observation: building the project produces untracked git
> files.
> > >> Should we update gitignore accordingly?
> > >>
> > >>
> > >> Thanks,
> > >> Pavel
> > >>
> > >>
> > >> On Tue, Jun 30, 2020 at 9:33 PM Ivan Daschinsky 
> > >> wrote:
> > >>
> > >> > Ok, CMake now is the only option to build C++ on non-windows
> > platforms.
> > >> > Autotools is removed from master.
> > >> >
> > >> > Many thanks to Igor Sapego, Zhenya Stanilovsky, Nickolay Izhikov and
> > >> Ilya
> > >> > Kasnacheev for review, testing and suggestions.
> > >> >
> > >> > вт, 23 июн. 2020 г. в 18:42, Ivan Daschinsky :
> > >> >
> > >> > > I suppose, that removal of autotools from source code is a
> question
> > >> of a
> > >> > > week. There is no need to support it.
> > >> > >
> > >> > > вт, 23 июн. 2020 г., 18:38 Ilya Kasnacheev <
> > ilya.kasnach...@gmail.com
> > >> >:
> > >> > >
> > >> > >> Hello!
> > >> > >>
> > >> > >> Once you do that, I think it would make sense to remove autotools
> > >> > >> invocation from artifact build process. In the future we may
> choose
> > >> to
> > >> > >> remove autotools support entirely.
> > >> > >>
> > >> > >> Regards,
> > >> > >> --
> > >> > >> Ilya Kasnacheev
> > >> > >>
> > >> > >>
> > >> > >> вт, 23 июн. 2020 г. в 18:00, Petr Ivanov :
> > >> > >>
> > >> > >> > That host was down for some time and got up only recently.
> > >> > >> > Installed cmake there also.
> > >> > >> >
> > >> > >> >
> > >> > >> >
> > >> > >> > > On 23 Jun 2020, at 17:39, Ivan Daschinsky <
> ivanda...@gmail.com
> > >
> > >> > >> wrote:
> > >> > >> > >
> > >> > >> > > Petr, I see, that cmake is missing on aitc10_05 but it is in
> > pool
> > >> > and
> > >> > >> > > tr

Re: Partitioned mode issue

[Toni Mateu Sanchez]

Thanks!



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

Re: Ignite thin client in Rust

[Pavel Tupitsyn]

Hi Val,

This is great!
I'm a Rust enthusiast too, the language is awesome.
Is it time to rewrite Ignite in Rust? :)

In all seriousness, do you have plans to continue working
on this thin client and make it production-ready?

On Wed, Jul 1, 2020 at 8:01 AM Valentin Kulichenko <
valentin.kuliche...@gmail.com> wrote:

> Igniters,
>
> I've been learning the Rust language lately and though that creating a thin
> client in Rust would be a great exercise.
>
> I went ahead and create a prototype which currently supports only put and
> get operations with primitives and strings:
> https://github.com/vkulichenko/ignite-rust-client
>
> Feedback and participation are welcome!
>
> Do we have any Rust enthusiasts in our community?
>
> -Val
>

Re: [DISCUSSION] Ignite.C++ and CMake

[Pavel Tupitsyn]

I think we could add a script or two, like cmake-build.sh and ctest.sh,
which work right away and can be used as a reference.

This is useful for Igniters like me who need to check some C++ related
things quickly,
but do that rarely enough to forget the build system quirks.

On Wed, Jul 1, 2020 at 10:53 AM Ivan Daschinsky  wrote:

> No, I am really curious if this instruction complete or not. Actually, Ilya
> Kasnacheev asked me about the same thing as you. And may be instruction is
> not so obvious and should be reworked. You know, that developers are not
> usually great in writing documentation.
>
> ср, 1 июл. 2020 г., 10:37 Pavel Tupitsyn :
>
> > Ivan,
> >
> > Thank you for such a detailed explanation!
> > I am sorry if I upset you.
> >
> > I just wanted to make sure that instructions are correct,
> > and I simply missed those 2 dots. Now it all works perfectly.
> >
> > Pavel
> >
> > On Wed, Jul 1, 2020 at 8:09 AM Ivan Daschinsky 
> > wrote:
> >
> > > Let me explain with details.
> > >
> > > CMake is unusual from other build systems, that it can separate build
> > root
> > > and source root. Moreover, it is strongly discouraged to mix them.
> > > Benefits:
> > > 1. You can have many build with different options using same source.
> > > 2. You can build project with different toolchain using same source.
> > > 3. You can build project for different platforms using same source
> > > (cross-compilation, docker, etc.)
> > >
> > > Common patter is:
> > > 1. Create build root.
> > > 2. Change current dir to build root.
> > > 3. Invoke cmake in build root, pointing to source root.
> > >
> > > Usually build root is subdirectory, of source root. So, as it mentioned
> > in
> > > DEVNOTES.txt, usual steps are:
> > > 1. mdkir  (usually named
> > cmake-build-[-]
> > > 2. cd 
> > > 3. cmake [-DOPTION1=VALUE1 -DOPTION2=VALUE2 ... ] .. (NB! This double
> > dots
> > > are important, they points to source root)
> > >
> > > This is so common, that you can hardly find any tutorial about CMake in
> > > google without thes double dots. This is basic of CMake.
> > >
> > > So if you think that we should explain for C++ developers basics of the
> > > most common build system (CMake is really very popular and nowadays
> > usually
> > > must for new projects),
> > > we can add this to DEVNOTES.txt. But I think that is not necessary at
> > all.
> > > For example, we don't explain basics of maven, though it is not obvious
> > at
> > > all as it seems to us, Ignite developers.
> > >
> > > ср, 1 июл. 2020 г. в 06:18, Ivan Daschinsky :
> > >
> > > > Pavel, pay attention to two dots at the end. All build files should
> > stay
> > > > at current dir, and cmake-build-release is supposed to be a build
> root.
> > > And
> > > > this directory is added to gitignore. Actually, build directory can
> be
> > > > everywhere, but you should pass path to dir, that contains root
> > > > CMakeLists.txt. Usually it is parent directory of
> cmake-build-release,
> > so
> > > > double dot is used. It is so common pattern of usage and I simply
> > cannot
> > > > understand why it is misleading.
> > > >
> > > > ср, 1 июл. 2020 г., 0:48 Pavel Tupitsyn :
> > > >
> > > >> This is awesome, thanks everyone!
> > > >>
> > > >> I've tried following the instructions, and the following two steps
> > seem
> > > to
> > > >> be misleading:
> > > >> * mkdir cmake-build-[release|debug]
> > > >> * cd ./cmake-build-[release|debug]
> > > >>
> > > >> When I run cmake in the newly created cmake-build-debug dir, I get:
> > > >> CMake Error: The source directory
> > > >> "/home/pavel/w/ignite/modules/platforms/cpp/cmake-build-release"
> does
> > > not
> > > >> appear to contain CMakeLists.txt.
> > > >>
> > > >> If I skip those 2 steps, I can build Ignite C++ and run tests with
> > ctest
> > > >> on
> > > >> Ubuntu 20.04.
> > > >>
> > > >>
> > > >> Another observation: building the project produces untracked git
> > files.
> > > >> Should we update gitignore accordingly?
> > > >>
> > > >>
> > > >> Thanks,
> > > >> Pavel
> > > >>
> > > >>
> > > >> On Tue, Jun 30, 2020 at 9:33 PM Ivan Daschinsky <
> ivanda...@gmail.com>
> > > >> wrote:
> > > >>
> > > >> > Ok, CMake now is the only option to build C++ on non-windows
> > > platforms.
> > > >> > Autotools is removed from master.
> > > >> >
> > > >> > Many thanks to Igor Sapego, Zhenya Stanilovsky, Nickolay Izhikov
> and
> > > >> Ilya
> > > >> > Kasnacheev for review, testing and suggestions.
> > > >> >
> > > >> > вт, 23 июн. 2020 г. в 18:42, Ivan Daschinsky  >:
> > > >> >
> > > >> > > I suppose, that removal of autotools from source code is a
> > question
> > > >> of a
> > > >> > > week. There is no need to support it.
> > > >> > >
> > > >> > > вт, 23 июн. 2020 г., 18:38 Ilya Kasnacheev <
> > > ilya.kasnach...@gmail.com
> > > >> >:
> > > >> > >
> > > >> > >> Hello!
> > > >> > >>
> > > >> > >> Once you do that, I think it would make sense to remove
> autotools
> > > >> > >> invocation from artifact build process. In the future we may

IGFS is alive: proposals of vertical solutions

[Manu]

Hi!

I read in other post that IGFS is going to be discontinued, isn't it?

I have a proposal to come alive again IGFS, it has interesting applications,
this could be one:
 



--
Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/

[jira] [Created] (IGNITE-13198) Calcite integration. Rework error / cancle login on execution

[Taras Ledkov (Jira)]

Taras Ledkov created IGNITE-13198:
-

 Summary: Calcite integration. Rework error / cancle login on 
execution
 Key: IGNITE-13198
 URL: https://issues.apache.org/jira/browse/IGNITE-13198
 Project: Ignite
  Issue Type: Improvement
  Components: sql
Reporter: Taras Ledkov
Assignee: Taras Ledkov


Change error & cancel logic on query execution.
*Error*
- propagated from source to downstream nodes.
- Always propagated to the RootNode;
- RootNode receive an error and cancel all execution tree.

*Cancel*
- propagated from downstream to source;
- any node may cancel its execution sub-tree;
- (technical details) to prevent race on Inbox creation Outbox resend Cancel 
message to Inbox.





--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13199) Apache Ignite Binary Serialization between .NET Core and Java is not working

[Chris Paraskeva (Jira)]

Chris Paraskeva created IGNITE-13199:


 Summary: Apache Ignite Binary Serialization between .NET Core and 
Java is not working
 Key: IGNITE-13199
 URL: https://issues.apache.org/jira/browse/IGNITE-13199
 Project: Ignite
  Issue Type: Bug
  Components: binary
Affects Versions: 2.8.1
 Environment: * OS: Windows 10 10.0 amd64
 * VM information: Java(TM) SE Runtime Environment 11.0.5+10-LTS Oracle 
Corporation Java HotSpot(TM) 64-Bit Server VM 11.0.5+10-LTS
 * Apache Ignite 2.8.1 version
Reporter: Chris Paraskeva
 Fix For: 2.9


I have run into issue where I use a group of Apache Ignite (2.8.1) server nodes 
in .NET core to create a data grid and run queries to the grid via an Apache 
ignite java client. I have not problem at all writing data in binary mode to 
the grid and ask queries via the think layer provided. I use DBeaver to run 
queries and everything is fine as expected. The issue rise while I am trying to 
query data from a java client which complains about a conflict in cache ": 
Conflicts during configuration merge for cache MY_CAHE". Find the error message 
below:

 

Caused by: class org.apache.ignite.spi.IgniteSpiException: Conflicts during 
configuration merge for cache 'DOTNET_BINARY_CACHE' : 
TRADE conflict: 
keyType is different: local=Apache.Ignite.Core.Cache.Affinity.AffinityKey, 
received=org.apache.ignite.cache.affinity.AffinityKey
valType is different: 
local=Servicing.Agent4.Service.Implementation.Misc.Ignite.Trade, 
received=Servicing.Agent4.Core.Java.Models.Trade



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13200) SQL create index on invalid data type

[Taras Ledkov (Jira)]

Taras Ledkov created IGNITE-13200:
-

 Summary: SQL create index on invalid data type
 Key: IGNITE-13200
 URL: https://issues.apache.org/jira/browse/IGNITE-13200
 Project: Ignite
  Issue Type: Bug
  Components: sql
Affects Versions: 2.8.1
Reporter: Taras Ledkov
Assignee: Taras Ledkov
 Fix For: 2.9


*Reproduce*
- Create cache with value class
{code}
private static class Value {
@QuerySqlField
int val_int;
java.util.Date val_date;
}
{code}
- alter table with command
{{ALTER TABLE TEST ADD COLUMN (VAL_DATE DATE)}}
- try to create index with command
{{CREATE INDEX TEST_VAL_DATE_IDX ON TEST(VAL_DATE)}}

{{CorruptedTreeException}} is thrown, the node is stopped.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

[jira] [Created] (IGNITE-13201) Visor hangs indefinitely if can't reach out to server/client due to networking issues

[Denis A. Magda (Jira)]

Denis A. Magda created IGNITE-13201:
---

 Summary: Visor hangs indefinitely if can't reach out to 
server/client due to networking issues
 Key: IGNITE-13201
 URL: https://issues.apache.org/jira/browse/IGNITE-13201
 Project: Ignite
  Issue Type: Improvement
Affects Versions: 2.8.1
Reporter: Denis A. Magda


It's reported here that Visor hangs if a node is unreachable due network 
configuration specificities when the tool is attempting to collect metrics from 
that node:
http://apache-ignite-users.70518.x6.nabble.com/How-to-do-address-resolution-td33145.html

Instead of hanging indefinitely, Visor has to fail on timeout and print a 
message that suggests checking network configuration settings.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Re: IGFS is alive: proposals of vertical solutions

[Denis Magda]

Hi Many,

Yes, your understanding is correct. The IGFS is being phased out:
https://issues.apache.org/jira/browse/IGNITE-11942

You can always take its source code and keep using for your project. I just
wonder is there any reason of why Kafka or Pulsar doesn't work for the
queuing use case you mentioned?

-
Denis


On Wed, Jul 1, 2020 at 2:27 AM Manu  wrote:

> Hi!
>
> I read in other post that IGFS is going to be discontinued, isn't it?
>
> I have a proposal to come alive again IGFS, it has interesting
> applications,
> this could be one:
> <
> http://apache-ignite-developers.2346864.n4.nabble.com/file/t242/ehc-queue.png>
>
>
>
>
> --
> Sent from: http://apache-ignite-developers.2346864.n4.nabble.com/
>

Re: Ignite thin client in Rust

[Valentin Kulichenko]

Pavel,

Yes, I definitely plan to continue working on this going forward. No
deadlines though :)

-Val

On Wed, Jul 1, 2020 at 1:09 AM Pavel Tupitsyn  wrote:

> Hi Val,
>
> This is great!
> I'm a Rust enthusiast too, the language is awesome.
> Is it time to rewrite Ignite in Rust? :)
>
> In all seriousness, do you have plans to continue working
> on this thin client and make it production-ready?
>
> On Wed, Jul 1, 2020 at 8:01 AM Valentin Kulichenko <
> valentin.kuliche...@gmail.com> wrote:
>
> > Igniters,
> >
> > I've been learning the Rust language lately and though that creating a
> thin
> > client in Rust would be a great exercise.
> >
> > I went ahead and create a prototype which currently supports only put and
> > get operations with primitives and strings:
> > https://github.com/vkulichenko/ignite-rust-client
> >
> > Feedback and participation are welcome!
> >
> > Do we have any Rust enthusiasts in our community?
> >
> > -Val
> >
>

[jira] [Created] (IGNITE-13202) Javadoc HTML can't be generated correctly with maven-javadoc-plugin on JDK 11+

[Aleksey Plekhanov (Jira)]

Aleksey Plekhanov created IGNITE-13202:
--

 Summary: Javadoc HTML can't be generated correctly with 
maven-javadoc-plugin on JDK 11+
 Key: IGNITE-13202
 URL: https://issues.apache.org/jira/browse/IGNITE-13202
 Project: Ignite
  Issue Type: Bug
Reporter: Aleksey Plekhanov


Javadoc utility has some bugs which don't allow to build Ignite Javadocs 
correctly.

Building javadoc under JDK 11+ throws an error "The code being documented uses 
modules but the packages defined in
https://docs.oracle.com/javase/8/docs/api are in the unnamed module". To 
workaround this error argument "source=1.8" can be specified, but there is 
another bug related to "source" and "subpackages" argument usages: 
[https://bugs.openjdk.java.net/browse/JDK-8193030.] We still can build javadoc 
with disabled {{detectJavaApiLink}} maven-javadoc-plugin option, but in this 
case there will be no references to Java API from Ignite Javadoc.  

Also, there is a bug with "-exclude" argument in JDK 11+, it doesn't exclude 
subpackages of specified to exclude packages, so in generated output there is a 
lot of javadocs for internal packages. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)