Hm... I actually don't like the complexity of creating a DeploymentProvider for every deployment source. How about we just use URI-like approach?
git://my.git.repository/master svn://... file:///.... mvn:my.maven.artifact etc... This way we can simply have a collection of URIs as a parameter to the deploy method. At implementation level we can have a different DeploymentProvider for each deployment protocol we support. D. On Mon, Jul 27, 2015 at 5:43 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > On Mon, Jul 27, 2015 at 12:32 PM, Alexey Goncharuk < > alexey.goncha...@gmail.com> wrote: > > > 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. > > > > > Agree. deploy() method should take smth like DeploymentProvider interface > with getArtifacts() method. We can also add it as a configuration property > to apply automatically on startup. > > I'm also not sure about -deploy option for ignite.sh. It seems to me that > deployment should be used by an application that deployed it. What can a > standalone node do with it? > > > > 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. > > > > I think ability to redeploy (and therefore undeploy) is a must here. > Otherwise you will need to restart the cluster each time you have changes. > This makes the feature useless. > > > > > > --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, > > > > > > > > > >
