Regarding the phrase: "We assume that p2p and deployment SPI will be removed from Ignite"
I think we shouldn't remove old implementations (p2p classloading and deployment SPI). As far as I know these functionalities have users. Removing any of these implementations will force users to change their code. From my point of view all deployment methods can coexist. Also, I think P2P classloading is a very useful feature for quick-starting. The new deployment functionality requires additional steps from users, p2p classloading can be more convenient in some scenarios. пн, 2 мар. 2026 г. в 22:57, Alex Plehanov <[email protected]>: > > +1 for something containing "deployment": > 1. Naming consistency with "Deployment SPI". Even if it will be > removed later, it solves the same problem. > 2. Naming consistency with Ignite 3. > 3. IgniteClassPath sounds like some system-property, where we can set > some path, but not something that we can upload to the server. > > чт, 26 февр. 2026 г. в 14:47, Maksim Timonin <[email protected]>: > > > > Hi, > > > > I suppose that being *java-centric* is one of the core features of Ignite > > (at least for 2.x), so terms should be self-explanatory for java > > developers. IgniteClassPath is a good term, whereas DeploymentUnit feels > > too general. The term "deployment" is somewhat misleading here because it > > carries a specific, different meaning in Kubernetes (and looks like MongoDB > > uses it in the same way). > > > > I also find possible CLI syntax very intuitive for developers: > > ./control.sh [compute|service...] --run MyTask --class-path id. (or even > > -cp) > > > > Also, Spark and Flink use explicit cli options for non-java resources (for > > example, --py-files, --pyFiles). I think we can implement similar explicit > > APIs for other languages in the future, if required. > > > > > > On Wed, Feb 25, 2026 at 4:30 PM Anton Vinogradov <[email protected]> wrote: > > > > > +1 to ClassPath since in because of java > > > > > > On Wed, Feb 25, 2026 at 12:12 PM Nikolay Izhikov <[email protected]> > > > wrote: > > > > > > > Hello. > > > > > > > > > If you look at the Apache Spark and Flink examples, we can specify > > > where > > > > the jars will be taken from(local, hdfs, http, https, ftp). Will this > > > > functionality be supported? > > > > > > > > Yes, but via extensions. > > > > > > > > > If so, perhaps it would be useful to create a whitelist of resources > > > > from which resources can be loaded? > > > > > > > > Useful insight. Will add it in IEP. > > > > > > > > ср, 25 февр. 2026 г. в 11:35, ткаленко кирилл <[email protected]>: > > > > > > > > > > Hi. > > > > > > > > > > I agree with colleagues about the "Deployment Unit" term. > > > > > The IEP provides example commands specifying additional jars, but you > > > > have an idea to add both jars and other resources. I think it would be > > > very > > > > useful to add other libraries for the languages we support this way. > > > > > > > > > > If you look at the Apache Spark and Flink examples, we can specify > > > where > > > > the jars will be taken from(local, hdfs, http, https, ftp). Will this > > > > functionality be supported? > > > > > If so, perhaps it would be useful to create a whitelist of resources > > > > from which resources can be loaded? > > > > > > > > > > Will there be separate permissions for the add/remove resource > > > commands? > > > > > > >
