Agree. URIs are not flexible enough. But we still can have UriDeploymentProvider for protocols that fit there (file, HTTP, FTP, etc.). Definitely no need to create a separate provider for each of them.
-Val On Tue, Jul 28, 2015 at 10:19 AM, Alexey Goncharuk < alexey.goncha...@gmail.com> wrote: > I still do not like this approach. Maven artifacts may require another URL > for an external repository, now we would have to encode a URI into another > URI. The git repository may require some settings for a build system, which > also may not always be expressed in terms of URI parameters. > > Besides, if I understood correctly, we should still leave a room for users > to implement their own provider that will parse an URI and provide > artifacts, which is the exact interface suggested by Val, but > getArtifacts() method now has an URI as an argument. But instead of passing > these providers to deploy() method, we need to set them in configuration. > > 2015-07-28 1:47 GMT-07:00 Dmitriy Setrakyan <dsetrak...@apache.org>: > > > 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, > > > > > > > > > > > > > > > > > > > > >
