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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >> > <[email protected]> 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: [email protected] >> >> >> >> >> >> >> >> >> >> On Tuesday, November 3, 2015 4:52 PM, Matthew Burgess < >> [email protected]> 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 <[email protected]> >> >> Reply-To: <[email protected]> >> >> Date: Tuesday, November 3, 2015 at 12:34 PM >> >> To: <[email protected]> >> >> 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. >>
