Guys,
I'm not sure I understand the purpose of this discussion. Maven-based and
Git-based providers are just examples of pluggable implementations that we
can provide out of the box - user is never forced to use them.
I see two main use cases for the feature:
- Dynamic deployment and redeploy
>
> It's called a remote code execution exploit. Anyone who has write access
> to the repo (i.e., anyone who can hack in) can change the deployed code
> and DOS your whole cluster.
>
I believe these decisions are best left to the end user, the mechanism
proposed may or may not have valid uses for
On Tue, Jul 28, 2015 at 10:16PM, Branko Čibej wrote:
> On 28.07.2015 21:36, Dmitriy Setrakyan wrote:
> >> Cos, we are not talking about checking binaries. We are planning to
> > support
> >
> >>> GIT/SVN/etc repositories with a POM file. This way we simply build it
> >>> using maven ourselves and
On 28.07.2015 21:36, Dmitriy Setrakyan wrote:
>> Cos, we are not talking about checking binaries. We are planning to
> support
>
>>> GIT/SVN/etc repositories with a POM file. This way we simply build it
>>> using maven ourselves and deploy it.
>> Well, even worst IMO. Why would you want to run an
On Tue, Jul 28, 2015 at 12:36PM, Dmitriy Setrakyan wrote:
> > Cos, we are not talking about checking binaries. We are planning to
> support
>
> > > GIT/SVN/etc repositories with a POM file. This way we simply build it
> > > using maven ourselves and deploy it.
> >
> > Well, even worst IMO. Why wo
> Cos, we are not talking about checking binaries. We are planning to
support
> > GIT/SVN/etc repositories with a POM file. This way we simply build it
> > using maven ourselves and deploy it.
>
> Well, even worst IMO. Why would you want to run an external build
> process as a part of the nodes d
On Tue, Jul 28, 2015 at 11:31AM, Dmitriy Setrakyan wrote:
> On Tue, Jul 28, 2015 at 11:20 AM, Konstantin Boudnik wrote:
>
> > 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
On Tue, Jul 28, 2015 at 11:20 AM, Konstantin Boudnik wrote:
> 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 wo
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(...
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://
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
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
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 thin
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-th
+1 for the feature. Looks like really good usability enhancement.
-Val
On Sun, Jul 26, 2015 at 10:31 PM, Dmitriy Setrakyan
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.
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 eit
17 matches
Mail list logo
