On Tue, Jul 28, 2015 at 11:31AM, Dmitriy Setrakyan wrote: > On Tue, Jul 28, 2015 at 11:20 AM, Konstantin Boudnik <c...@apache.org> 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 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? > > > > 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 deployment? This will pose a security risk in the production deployment and you will have to find a way to disable this in some case and allow it in the others, no? > > > 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 ;) > > > > The implementation of MvnDeploymentProvider may very well delegate to some > very well known library. > > DeploymentProvider should be a generic Ignite abstraction that has > different implementations for different deployment sources, mainly to > decouple Ignite from specific 3rd party library implementations. Good point, agree. Still don't like the the git://, svn:// stuff though ;) Cos
