As an additional data point Hadoop does this as well. So Hadoop, Spark, and HBase easily three of the most widely built open source projects around do this.
Thanks Joe On Fri, Nov 6, 2015 at 1:01 PM, Joe Witt <joe.w...@gmail.com> wrote: > What are some examples of networks which can access maven central but > cannot access JCenter? > > Thanks > Joe > > On Fri, Nov 6, 2015 at 12:10 PM, Adam Taft <a...@adamtaft.com> wrote: >> I'm concerned that not all networks will be able to connect with and use >> the JCenter repository. If it's not in Maven Central, we should likely >> avoid the dependency and instead find alternative approaches. >> >> Adam >> >> >> >> On Fri, Nov 6, 2015 at 11:31 AM, Joe Witt <joe.w...@gmail.com> wrote: >> >>> joe explained to me he meant to update the nifi pom.xml with this >>> repository. Today we use whatever the apache pom (which we extend >>> from uses) which for releases is nothing which means it is whatever >>> maven defaults to (presumably maven central). So we see that spark >>> does this explicit addition of repositories on their pom for both >>> primary artifacts and plugins. >>> >>> My concern with this is that our requirement as a community is to >>> provide repeatable builds. We looked into what Hbase and Spark do and >>> in fact both of them extend their poms to depend on other repos as >>> well so there is precedent. >>> >>> In light of finding other apache projects that use extra repositories >>> and the fact that Jcenter Bintray while being a commercially focused >>> repo is offering free support for OSS artifacts then I think the risk >>> is low. I am ok with this. >>> >>> Anyone have a different view? >>> >>> Thanks >>> Joe >>> >>> On Fri, Nov 6, 2015 at 11:04 AM, Joe Witt <joe.w...@gmail.com> wrote: >>> > Joe >>> > >>> > Sorry i didn't catch this thread sooner. I am not supportive of >>> > adding a required repo if it means we need to tell folks to update >>> > their maven settings. While it sounds trivial it really isn't. We >>> > should seek to understand better what other projects do for such >>> > things. Definitely no fast movement on this one please. >>> > >>> > Thanks >>> > Joe >>> > >>> > On Fri, Nov 6, 2015 at 10:18 AM, Joe Percivall >>> > <joeperciv...@yahoo.com.invalid> wrote: >>> >> As no issues were brought up, I'm going to assume that everyone is ok >>> with adding Bintray JCenter as a repo. I plan on using it in a patch for >>> 0.4.0 in which I'm refactoring InvokeHttp. The patch is dependent on a lib >>> to add digest authentication that is only hosted there. >>> >> >>> >> Thanks, >>> >> Joe >>> >> - - - - - - >>> >> Joseph Percivall >>> >> linkedin.com/in/Percivall >>> >> e: joeperciv...@yahoo.com >>> >> >>> >> >>> >> >>> >> >>> >> On Tuesday, November 3, 2015 4:52 PM, Matthew Burgess < >>> mattyb...@gmail.com> wrote: >>> >> Bintray JCenter (https://bintray.com/bintray/jcenter/) is also >>> moderated and >>> >> claims to be "the repository with the biggest collection of Maven >>> artifacts >>> >> in the world". I think Bintray itself proxies out to Maven Central, but >>> it >>> >> appears that for JCenter you choose to sync your artifacts with Maven >>> >> Central: http://blog.bintray.com/tag/maven-central/ >>> >> >>> >> I imagine trust is still a per-organization or per-artifact issue, but >>> >> Bintray claims to be even safer and more trustworthy than Maven Central >>> >> (source: >>> >> http://blog.bintray.com/2014/08/04/feel-secure-with-ssl-think-again/). >>> For >>> >> my (current) work and home projects, I still resolve from Maven >>> Central, but >>> >> I have been publishing my own artifacts to Bintray. >>> >> >>> >> Regards, >>> >> Matt >>> >> >>> >> From: Aldrin Piri <aldrinp...@gmail.com> >>> >> Reply-To: <dev@nifi.apache.org> >>> >> Date: Tuesday, November 3, 2015 at 12:34 PM >>> >> To: <dev@nifi.apache.org> >>> >> Subject: Incorporation of other Maven repositories >>> >> >>> >> >>> >> I am writing to see what the general guidance and posture is on >>> >> incorporating additional repositories into the build process. >>> >> >>> >> Obviously, Maven Central provides a very known quantity. Are there >>> other >>> >> repositories that are viewed with the same level of trust? If so, is >>> there >>> >> a listing? If not, do we vet new sources as they bring libraries that >>> aid >>> >> our project and how is this accomplished? >>> >> >>> >> Incorporating other repos brings up additional areas of concern, >>> >> specifically availability but also some additional security >>> considerations >>> >> to the binaries that are being retrieved. >>> >> >>> >> Any thoughts on this front would be much appreciated. >>>
