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