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