I like the idea, however I do not like the API. Why do we need to limit deployment process to a list of files or GIT repositories? What if I want to build artifacts from Mercurial using gradle? I think the entity that provides artifacts should be an interface and Ignite should provide an out-of-the-box set of builders that can fetch files or Maven artifacts or build GIT repos with pom files.
Besides the API, we should describe how the deployment process interacts with other Ignite subsystems. For example, once artifacts are deployed, they should be made available on joining nodes on early stages of discovery, so that dynamic cache start feature can use those classes to instantiate cache store. Should we provide a method to undeploy artifacts? If yes, we should gracefully clean up all components that may have used deployed code: stop caches, distributed services, tasks. Looks like deploy() should return an instance of Ignite which has a deployment context, and deployed classes should be made available only for method invocations made on that particular Ignite instance. --AG 2015-07-27 11:49 GMT-07:00 Valentin Kulichenko < valentin.kuliche...@gmail.com>: > +1 for the feature. Looks like really good usability enhancement. > > -Val > > On Sun, Jul 26, 2015 at 10:31 PM, Dmitriy Setrakyan <dsetrak...@apache.org > > > wrote: > > > Igniters, > > > > So far Ignite deployment process left it up to a user to deploy all the > > libraries on all the nodes manually, before a node can even be started > up. > > > > What about adding *Ignite.deploy(...)* method that could do the > deployment > > automatically? As parameters to this method, it could receive either a > URI > > of the user archives, a GIT repository, or Maven repositories and > > artifacts. > > > > I have described the design here: > > https://issues.apache.org/jira/browse/IGNITE-1160 > > > > Please provide comments on whether you think this functionality is useful > > or sufficient. > > > > D, > > >
