Very surprising, I really tough Bintray was a cloud of Artifactory instances...
Since the main use case is to support Bintray jcenter I think you should concentrate on Bintray APi support only and skip Artifactory for now. On Fri, Jun 9, 2017 at 3:12 PM, Krzysiek Płachno <[email protected]> wrote: > I've investigater Artifactory and Bintray APIs. They are totally different. > > I updated desing page: > http://design.xwiki.org/xwiki/bin/view/Proposal/MoreextensionrepositoriesArtifactoryBintray > > 2017-06-08 11:35 GMT+02:00 Krzysiek Płachno <[email protected]>: > >> Ok - I got it (I confused in my mind ExtensionRepositorySource >> with ExtensionRepository) >> >> I'll compare in detail the apis of Artifactory and Bintray - if they're >> (almost) the same - it makes sense to do it as you described. >> >> KP >> >> 2017-06-08 11:26 GMT+02:00 Thomas Mortagne <[email protected]>: >> >>> On Thu, Jun 8, 2017 at 11:05 AM, Krzysiek Płachno >>> <[email protected]> wrote: >>> > Ok - then. >>> > >>> > So: >>> >>> > 1. Do I understand well that the advantage of Rest connection over >>> native >>> > Maven connection is that when using maven we cannot search repo? >>> >>> Yes you don't have live search in standard Maven repository. In some >>> repository you can download an index but that's all. >>> >>> > 2. The goal would be to produce an extension with two components >>> > ExtensionRepositoryFactory: 'bintray' and 'artifactory' which sharing >>> the >>> > same logic will allow to connect Bintray and Artifactory? Or just >>> > one ExtensionRepositoryFactory with name 'artifactory' to be used also >>> for >>> > both? This naming is a bit important since in xwiki.properties whilst >>> > giving url to external repo user also gives type of repo. (As >>> > regards ExtensionRepositorySource components - they are completely >>> hidden >>> > so it may be one for both Artifactory and Bintray) >>> >>> If Bintray use Artifactory REST API then there should be only one >>> 'artifactory' ExtensionRepositoryFactory. >>> >>> ExtensionRepositorySource point is to provide default repository (for >>> example extensions.xwiki.org or nexus.xwiki.org) so it only make sense >>> for Bintray jcenter (unless jcenter does not expose REST API). I >>> totally skipped the fact that anyone was able to create a Bintray >>> instance and I was actually only thinking about jcenter. >>> >>> > >>> > KP >>> > >>> > >>> > >>> > >>> > 2017-06-07 10:12 GMT+02:00 Thomas Mortagne <[email protected]>: >>> > >>> >> Some comments: >>> >> >>> >> The difference between Artifactory and Bintray you are describing >>> >> don't really matter for your use case IMO. >>> >> >>> >> The only thing you should deal with are: >>> >> >>> >> * downloading artifacts >>> >> * searching for artifacts (that is actually the only feature brought >>> >> by this extension since as you said you can download artifacts through >>> >> Maven access) >>> >> >>> >> and AFAIK those two features have the same API in both cases since >>> >> Bintray is essentially a public Artifactory instance. >>> >> >>> >> So unless I really missing something here you should IMO work on two >>> >> extensions (on just two component in the same extension): >>> >> * an ExtensionRepositoryFactory for Artifactory >>> >> * a ExtensionRepositorySource which automatically register Bintray >>> >> with the type "artifactory" >>> >> >>> >> On Mon, Jun 5, 2017 at 12:05 PM, Krzysiek Płachno >>> >> <[email protected]> wrote: >>> >> > Hey! >>> >> > >>> >> > I investigated a bit Binatray and Artifactory and uploaded relatively >>> >> short >>> >> > raport: >>> >> > http://design.xwiki.org/xwiki/bin/view/Proposal/ >>> >> MoreextensionrepositoriesArtifactoryBintray >>> >> > >>> >> > Any comments, ideas, relfections - highly appreciated. >>> >> > >>> >> > >>> >> > Best, >>> >> > Krzysztof Płachno >>> >> >>> >> >>> >> >>> >> -- >>> >> Thomas Mortagne >>> >> >>> >>> >>> >>> -- >>> Thomas Mortagne >>> >> >> -- Thomas Mortagne
