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