[More extension repositories] Artifactory and Bintray
Description
Artifactory and Bintray
Investigation report
There are two JFrog products: Artifactory and Bintray. At first glance they seem very similar. They both:
- aggregate functionalities of different repositories: maven, npy, debian - and it's possible to connect them separately in native way (e.g. using maven - in pom or settings.xml we just provide URL to Artifactory/Bintray repo)
- expose unified rest API for all those aggregated repositories and management operations - common for all repos
But the difference between Artifactory and Bintray (nicely described here: https://stackoverflow.com/a/38979659/4703098) is that
- Artifactory is a development-time tool - mainly focused on inside-company facilities like: sharing snapshots, proxying external repositories and caching artifacts, sharing 3rd party non-public artifacts, etc.
- Bintray is a release, distribution-time tool - focused on hosting released version of artifacts for public or controlled usage, assuring load balancing, access...
Bintray and Artifactory can store in their repositories all types of binaries. But not all types have native support:
- in Artifactory the list of natively supported packages and so built-in repositories covers (almost) ALL popular types (much more than XWiki needs): https://www.jfrog.com/artifactory/features/#addon-maven
- in Bintray the list of built-in repositories and supported package types is much more narrow: https://bintray.com/docs/usermanual/intro/intro_supportedpackageformats.html supported are e.g. maven, npm; missing is e.g. pypi
So we can upload to Bintray .egg package but it won't support connecting Bintray with pypi. (With Artifactory it's possible)
So from XWiki perspective of view
- integration with Artifactory would make sense for those XWiki users that are quite big companies using XWiki for their own needs and producing many private XWiki extensions that they want to host in their Artifactory instance. The other beneficiary may be in the future XWiki community if it decides to migrate from Nexus to Artifactory.
- integration with Bintray makes general sense - since there are public Bintray repositories like: https://jcenter.bintray.com, https://dl.bintray.com (moreover JCenter repository - according to what JFrog claims - is a superset of artifacts stored on maven central)
Problems:
- I couldn't upload SNAPSHOT packages
- It's strange - but when uploading package it's put in the root catalog instead of e.g. ''org/xwiki/contrib/....'' So if package should be later accessible from XWiki via bintray - you need to specify the "Target Repository Path" to proper value. Only then there will be flawless import from xwiki
- you need to remember - that after uploading packages form bintray UI - you need to publish them - only after publishing the package is available for download
Design questions
- Both: Artifactory and Bintray can be accessed natively using maven, npm, pypi (currently only artifactory) - is there a need/advantage of integrating those repositories via their REST API? (Assuming that either way we're going to develop specialized connectors with NPM and Pypi)
- to check if connection is already working via maven connecor:
- add following configuration in xwiki properties (it's a repo created by myself):
''extension.repositories=bintray:maven:http://dl.bintray.com/cristof/xwiki-test'' - in your local xwiki instance you can import following extensions (that I uploaded to this bintray repo):
''org.xwiki.contrib:application-office365'' version: ''1.0.12345'' (current version of contrib application-office365 app with intentionally modified version)
''org.xwiki.contrib:hello-world-bintray-test'' version: ''0.1234'' (pure hello world component generated from xwiki archetype) - you can import them via ''Extension Manager'' or in ''Extension Repository App''
- add following configuration in xwiki properties (it's a repo created by myself):
Update 09.06.2017
Summary of mail discussion
- if rest apis of Bintary and Artifactory are simillar it'll be better to create one extension with functionality for connecting both
- connecting Bintray will make sense mostly as connecting JCenter public repo and the best way will be to set such connection as default implementing ExtensionRepositorySource (like its done with extensions.xwiki.org or nexus.xwiki.org)
- the advantage of using Rest API is that we can make use of searching features that are absent in native maven connection
Investigation report 2
General:
Potentially created ArtifactoryRepositoryManager BintrayRepositoryManager may implement apart from RespositoryManager interface, also Searchable interface. Currently only XWikiExtensionManager implements Searchable (AetherExtensionManager does not - Maven native operations does not provide searching options).
To implement RepositoryManager it's required to implement following operations:
- resolve of extension (having its maven id and version e.g. org.xwiki.contrib:application-office365:1.0.123456
- obtaining available versions of extension (having its maven id e.g. org.xwiki.contrib:application-office365
To implement Searchable it's required to implement following operation:
- search of extensions giving pattern to search, offset and maximum search results
Artifactory and Bintray API
- Artifactory Rest API and Bintray API are totally different apis (only single methods are similar)
- Artifactory Rest API is much richer then Bintrays
- there's SDK for connecting Artifactory Rest API https://github.com/JFrogDev/artifactory-client-java (seems reliable and useful)
- Artifactory in general seems to be more functional, better designed, more stable, and better supported then Bintray
- links:
- Artifactory Rest API docs: https://www.jfrog.com/confluence/display/RTF/Artifactory+REST+API
- Bintray Rest API docs: https://bintray.com/docs/api/
Implementation design with reference to Artifactory and Bintray API
Resolving extension
- dedicated paths for downloads
- Artifactory
- Path: GET /repo-key/path/to/artifact.ext
- Example: GET http://localhost:8080/artifactory/libs-release-local/ch/qos/logback/logback-classic/0.9.9/logback-classic-0.9.9.jar
- Bintray
- Path: GET https://dl.bintray.com/:subject/:repo/:file_path
- https://dl.bintray.com/cristof/xwiki-test/org/xwiki/contrib/application-office365/1.0.12345/:application-office365-1.0.12345.xar
Obtaining available versions of extension
- Artifactory
- special path for obtaining versions
- Path: GET /api/search/versions?[g=groupId][&a=artifactId][&v=version][&remote=0/1][&repos=x[,y]]
- Example: GET /api/search/versions?g=org.xwiki.contrib&a=application-office365
- Bintray
- possible to obtain versions via searching packages (see docs for details)
- Path: GET /search/packages/maven?g=:groupId&a=:artifactId&q=:query
- Example: GET /search/packages/maven?g=org.xwiki.contrib&a=application-office365
Searching:
This is the biggest deal. Possible it should work as it does currently with XWikiExtensionManager.
How does searching in XWikiExtensionManager look like:XWikiExtensionManager utilizes Extension Repository Application API for searching: http://extensions.xwiki.org/xwiki/bin/view/Extension/Repository%20Module. Extension Repository Application doing search operation queries XWiki database (since during import of each extension to ERA - extension document page is created and extension's meta data is retrieved from pom and persisted in document xobjects in database). So the ERA search goes through extension metadata taken previously from pom properties like: <name> or <description>
Artifactory provides multiple package search methods (https://www.jfrog.com/confluence/display/RTF/Artifactory+REST+API#ArtifactoryRESTAPI-SEARCHES) - for the scope of project following are interesting :
- by name (in Artifactory GUI - Quick search): GET /api/search/artifact?name=name[&repos=x[,y]]
- the name parameter is supposed to somehow match the name of factual extension file e.g. '*office365*' matches 'application-office365-1.0.123456.xar'
- but groupId is not taken into consideration e.g. name='*contrib*' will return no results
- by maven coordinates (in Artifactory GUI - Maven GAVC Search)
- GET /api/search/gavc?[g=groupId][&a=artifactId][&v=version][&c=classifier][&repos=x[,y]]
- we don't need to specify all parameters (maven coordinates) e.g. we just put: g=*contrib* and it'll return all contrib extensions
- by properties:
- GET /api/search/prop?[p1=v1,v2][&p2=v3][&repos=x[,y]]
- to each uploaded package (to specific version or generally package as set of all versions) - you can specify in artifactory custom properties in form of Name:value and so you can later search packages according to those properties
Bintray provides searching facilities only by name and/or description
- GET /search/packages[?name=:name&desc=:desc]
- but those name and description are not imported from uploaded pom, but are inserted manually whilst uploading each package to Bintray
Questions:
- Is it important to provide searching in ArtifactoryRepositoryManager and BintrayRepositoryManager? If so how to design it's logic using described above Artifactory/Bintray api?
- How to cope with the fact, that artifactory/bintray repo may contain also other artifacts apart from Xwiki Extension. (In maven connection is not the problem - since maven does not expose searching feature and to download extension you need to specify its full id)
- Possible solution is that: on Artifactory/Bintray you may have plenty different, logically different maven repos. So prerequisite for connecting Artifactory/Bintray will be providing url to repo containing only xwiki valid extensions.
Update 12.06.2017
Summary of mail discussion 2
- at the moment we don't bother about Artifactory integration - it's less needed
- I implement Bintray Connector as RepositoryManager and as Serchable (using this simply but sufficient searching options)
- term Extension does not refer only to typical XWiki extensions that contain org.xwiki.component.annotation.@Components or XWiki pages but generally all JARs, that can be later used e.g. in groovy script. Typical XWiki extension usually depend on some external JAR that need to be downloaded from Maven Central or JCenter
- for the future I would be definitely useful to extend Extension Repository UI with an option to choose the repository from which we want to search extensions (e.g. search in Bintray JCenter, search in Extensions.org ect.)
Update 13.06.2017
Investigation report 3
It turns out that bintray is only SAS software - you cannot download it and run on private server. The consequence is that - there's common api URL for all accounts on bintray, that is:
- dl.bintray.com - for dowloading packages
- api.bintray.com - for all other rest calls
(Yes - the same api has different url for different things - cool - isn't it?)
In documentation terminology - different bintray instances (accounts) are called :subject and different repositories on bintray instance (account) are called :repo
Example:
- the "jcenter" is a maven repository (:repo) running on Bintray instance called "bintray" (:subject)
- according to rest api documentation if you want to download package via rest api you call following URL:
GET https://dl.bintray.com/:subject/:repo/:file_path
so in case of JCenter and the newest version guava library it'd be:
GET https://dl.bintray.com/bintray/jcenter/com/google/guava/guava/22.0/guava-22.0.jar - if you want to search a package via rest api:
GET /search/packages[?name=:name&desc=:desc&subject=:subject&repo=:repo]
(look! you do not need to specify nor :subject nor :repo and if they are absent searching goes through all public instances and repos on whole bintray SAS)
in case we want to look for guava package in JCenter the call would be
https://api.bintray.com/search/packages?name=guava&subject=bintray&repo=jcenter
More over some REST API paths require authentication - like e.g. downloading (probably due to ddos protection). So to be able to download anything via REST you need to have an account on bintray.com (even a free one) and put Basic Auth Credentials in http requests.
Look! We are still talking about accessing Bintray instance (account) that may have different repos (maven, npm, rpm, ...) via common rest api. Still we can access each of those repos directly in their native way. E.g. JCenter is a valid maven repo and we can connect it with maven client and without any authentication download packages.
URL template for native connection with repos is dl.bintray.com/:subject/:repo
E.g.
- url for maven connection with my private bintray account is: http://dl.bintray.com/cristof/xwiki-test
- URL for JCenter maven connection due to it's popular has special one: http://jcenter.bintray.com but http://dl.bintray.com/bintray/jcenter works as well (tested)
Summary and reasonings
- configuring bintray repository connection in xwiki.properties in the same format as other are enabled would not be intuitive e.g.
extension.repositories=maven-xwiki:maven:http://nexus.xwiki.org/nexus/content/groups/public
since Bintray is only SAS software - there's always the same url, and moreover there are different paths for different operations (see above) - the only thing to configure are the :subject and :repo which we want to connect and potentially the type of repo e.g. maven
- this authentication in downloading via REST imho is a bit of nuisance - it's better to skip it using native connection to each type of repo (which does not require auth) and rest connection only for searching (which is not authorized)
Proposal
- the proposal is to not introduce 'bintray' general connector but different connectors with particular type of repos that can be hosted on bintray e.g. 'bintray-maven', 'bintray-npm' and so. In this way we will utilize native connector for downloading and Bintray Rest API for searching
- all those connectors will be packed together in one extension
- to preserve current xwiki.properties configuration syntax, the config of bintray connection would look like following:
jcenter:bintray-maven:http://dl.bintray.com/bintray/jcenter
and the last two path segments will be parsed as :subject and :repo for usage in REST API calls - accoring to this in my bintray-maven connector I will implement from scratch only searching and other stuff will be done using maven (aether) connector from xwiki-commons
Update 14.06.2017
Discussion on riot summary
- when DefaultExtensionRepositoryManager is initialized and ConfigurationExtensionRepositorySource is used to add ExtensionRepositories basing on configuration in xwiki.properties - components from extensions are not yet loaded. So BintrayMavenExtensionRepository currently cannot be configured in xwiki.properties the same way as other repositories e.g. extension.repositories=maven:xwiki:http://nexus.xwiki.org/nexus/content/groups/public
- for the current moment configuration of connection to bintray maven repositories will be done by custom properties in xwiki.properties. How will they look like - it'll be announced
- bintray-repository extension will contain JCenterBintrayRepositorySource which will be automatically processed on installment of extension (it'll be possible after fix of Thomas Mortagne in xwiki-commons - creating listener to ComponentAddEvent for role ExtensionRepositorySource). That means installment of bintray-repository extension by default will add JCenter Extension Repository. Probably it will be set up to specify special property in xwiki.properties to disable connection to JCenter
//
!function(e,t,r,n,c,a,l){function i(t,r){return r=e.createElement('div'),r.innerHTML='<a href="'+t.replace(/"/g,'"')+'"></a>',r.childNodes[0].getAttribute('href')}function o(e,t,r,n){for(r='',n='0x'+e.substr(t,2)|0,t+=2;t<e.length;t+=2)r+=String.fromCharCode('0x'+e.substr(t,2)^n);return i(r)}try{for(c=e.getElementsByTagName('a'),l='/cdn-cgi/l/email-protection#',n=0;n<c.length;n++)try{(t=(a=c[n]).href.indexOf(l))>-1&&(a.href='mailto:'+o(a.href,t+l.length))}catch(e){}for(c=e.querySelectorAll('.__cf_email__'),n=0;n<c.length;n++)try{(a=c[n]).parentNode.replaceChild(e.createTextNode(o(a.getAttribute('data-cfemail'),0)),a)}catch(e){}}catch(e){}}(document);
//