ID | IEP-93 |
Author | Mikhail Pochatkin |
Sponsor | |
Created |
|
Status | DRAFT |
Currently, Ignite 3 does not have a ready-made mechanism for delivering the required components to the user. The purpose of this IEP is to work out and create all kinds of options for packaging and distribution the required components of Ignite 3 to the user, taking into account the UX of various user platforms and OS.
As ready-made resulting packages, it is planned to make only completely independent parts of Apache Ignite. At the moment only Ignite core part and Ignite CLI can work as standalone applications and these applications should be distributed as OS specific packages for all supported platforms. (Linux, Windows, MacOs). However, we will publish not only compiled packages, there is a need to publish individual parts of Apache Ignite that are not standalone applications, and we need to provide the user with the access to these parts. The prime candidate for this is the ignite-client with all its subparts (JDBC, SQL Api, etc Api). More about this will be described in paragraph Publishing.
Three packages will be provided:
Every package will be available as a downloadable ZIP file, and as OS-specific packages (RPM, DEB, Brew …).
This package can only be used to connect to a remote (or local) cluster. Once the package is installed, the user gets access to the Ignite CLI tool via the ignite command.
The package includes:
NOTE: It is possible to build an ignite-cli executable with GraalVM native-image technology. This approach can provide a significant performance boost during CLI startup. This performance increase can be tested and presented to the community as part of this work.
This package provides an ability to run nodes on the local server. It includes:
Scripts can be used by a user directly, or by OS-level services. Mix-and-match of these two approaches should be disallowed.
This is a meta package that includes everything listed for the other two packages.
TBD. Currently IEP for odbc not ready.
TBD.
TBD
The issue of publishing assembled packages should be highlighted in a separate paragraph.
Each package should be published and available to install for all supported platforms by native OS way. It means that the installation process should respect all UX of each OS :
It is also necessary to support the publication of compiled images as zip files for the possibility of installation on those platforms where there are no default package managers. For each supported architecture, it is necessary to build and publish a zip file with everything necessary for the application to fully work (except for the third party dependencies, but this list should be attached to the REQUIRE.txt file).
Code examples should be moved to a separate Git repository and also provided as a separate ZIP download for every release.
Examples are NOT included in any of the packages described above.
// Describe project risks, such as API or binary compatibility issues, major protocol changes, etc.
// Links to discussions on the devlist, if applicable.
// Links to various reference documents, if applicable.
// Links or report with relevant JIRA tickets.