On Tue, Jul 28, 2015 at 10:29AM, Dmitriy Setrakyan wrote: > Alexey, > > I probably was not clear in my email earlier. I think that > DeploymentProvider is a good abstraction and we should have it. My comment > was that I would like it to be exposed as a URI string vs. "new > DeploymentProvider(...)". > > For example, GitDeploymentProvider would be configured as > "git://some.repo?param1=1¶m2=2"
I am missing a point of doing the git:, svn:, or any other vcs: URI, really. Checking binaries into a VCS system is very problematic and unclean thing to do, actually. Why would you encourage that with the proposed API? > As far as our point about Maven repositories, we can think of a way to > expose it artifacts and repo coordinates in a URI string. For example, we > can have "mvn://..." and "mvnrepo://" URIs. > > Does this make sense? I'd leave this job to the systems that already doing this and perhaps do it quite well. Why would you spend time developing your own mvn provider? Esp in the world that has gradle APIs? I have expressed this pow in the JIRA, so I will step out now ;) Cos > On Tue, Jul 28, 2015 at 10:19 AM, Alexey Goncharuk < > [email protected]> 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 <[email protected]>: > > > > > 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 < > > > [email protected]> wrote: > > > > > > > On Mon, Jul 27, 2015 at 12:32 PM, Alexey Goncharuk < > > > > [email protected]> 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 < > > > > > [email protected]>: > > > > > > > > > > > +1 for the feature. Looks like really good usability enhancement. > > > > > > > > > > > > -Val > > > > > > > > > > > > On Sun, Jul 26, 2015 at 10:31 PM, Dmitriy Setrakyan < > > > > > [email protected] > > > > > > > > > > > > > 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, > > > > > > > > > > > > > > > > > > > > > > > > > > >
