[xwiki-devs] [GSoC] More extension repositories [Bintray / Artifactory]
Hey! I investigated a bit Binatray and Artifactory and uploaded relatively short raport: http://design.xwiki.org/xwiki/bin/view/Proposal/MoreextensionrepositoriesArt... Any comments, ideas, relfections - highly appreciated. Best, Krzysztof Płachno
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/MoreextensionrepositoriesArt...
Any comments, ideas, relfections - highly appreciated.
Best, Krzysztof Płachno
-- Thomas Mortagne
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? 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) 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
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
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
I've investigater Artifactory and Bintray APIs. They are totally different. I updated desing page: http://design.xwiki.org/xwiki/bin/view/Proposal/MoreextensionrepositoriesArt... 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
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/MoreextensionrepositoriesArt...
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
Bintray JCenter may be connected even today using Maven Connector. Maven Connector does not allow for searching, but in the case of JCenter that stores in the vast major non-xwiki extensions searching is unnecessary. What's more - as I described on design page - bintray searching api allows only for searching matching search pattern with custom 'name' and 'description' given when uploading package - (see screenshot: https://image.ibb.co/m8wJqv/bintray.png) So the real advantage for XWiki will be integration with Artifactory. Of course I can still prepare extension resolving artifacts and versions of packages from Bintray via it's rest api, leaving space for future feature of searching when Bintray's API will be richer. The question is what's more usefull or needed. Best, Krzysztof 2017-06-09 15:23 GMT+02:00 Thomas Mortagne <[email protected]>:
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 <
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
On Fri, Jun 9, 2017 at 6:08 PM, Krzysiek Płachno <[email protected]> wrote:
Bintray JCenter may be connected even today using Maven Connector.
Maven Connector does not allow for searching, but in the case of JCenter that stores in the vast major non-xwiki extensions searching is unnecessary.
I don't think you understood the main goal of this project. The point is not to install XWiki stuff, Extension Manager can install any JARs and JCenter is full of useful JARs. Keep in mind that you can use any JAR you installed in scripts macros like Groovy.
What's more - as I described on design page - bintray searching api allows only for searching matching search pattern with custom 'name' and 'description' given when uploading package - (see screenshot: https://image.ibb.co/m8wJqv/bintray.png)
Everything on https://bintray.com/bintray/jcenter seems to have name and description and according to your screenshot the name is mandatory so this looks good enough to me.
So the real advantage for XWiki will be integration with Artifactory.
I don't know any public reference instance of Artifactory used by many open source projects to release artifacts like Bintray JCenter is. So no, supporting Artifactory add far less value for me.
Of course I can still prepare extension resolving artifacts and versions of packages from Bintray via it's rest api, leaving space for future feature of searching when Bintray's API will be richer. The question is what's more usefull or needed.
If it does not support search then it's useless.
Best, Krzysztof
2017-06-09 15:23 GMT+02:00 Thomas Mortagne <[email protected]>:
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 <
> 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
-- Thomas Mortagne
Bintray JCenter may be connected even today using Maven Connector.
Maven Connector does not allow for searching, but in the case of JCenter that stores in the vast major non-xwiki extensions searching is unnecessary.
I don't think you understood the main goal of this project. The point is not to install XWiki stuff, Extension Manager can install any JARs and JCenter is full of useful JARs.
Yes - it seems that I misunderstood. The name of the project was "More extension repositories" and in my application I wrote only about extensions. But anyway it does not change a lot for my project - if as you wrote "Extension Manager can install any JARs".
Of course I can still prepare extension resolving artifacts and versions of
packages from Bintray via it's rest api, leaving space for future feature of searching when Bintray's API will be richer. The question is what's more usefull or needed.
If it does not support search then it's useless.
It does support search but in very simple way as described on design page: http://design.xwiki.org/xwiki/bin/view/Proposal/MoreextensionrepositoriesArt... searching goes only thorough names and descriptions. So lets imagine that someone connects JCenter (Bintray) (with searching feature) in it's Xwiki instance, goes to Extension Magager and search for some extension putting e.g. LDAP. This will return a lot of results from JCenter (completely not needed), among which there'll be XWiki LDAP Authenticator extension - difficult to find. I see two solutions: - not enabling searching at all for Bintray - enabling searching of Bintray but, adding in Extension Manager UI option to select from which repository search WDYT?
Best, Krzysztof
2017-06-09 15:23 GMT+02:00 Thomas Mortagne <[email protected]>:
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 <
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
-- Thomas Mortagne
On Sun, Jun 11, 2017 at 6:11 PM, Krzysiek Płachno <[email protected]> wrote:
Bintray JCenter may be connected even today using Maven Connector.
Maven Connector does not allow for searching, but in the case of JCenter that stores in the vast major non-xwiki extensions searching is unnecessary.
I don't think you understood the main goal of this project. The point is not to install XWiki stuff, Extension Manager can install any JARs and JCenter is full of useful JARs.
Yes - it seems that I misunderstood. The name of the project was "More extension repositories" and in my application I wrote only about extensions. But anyway it does not change a lot for my project - if as you wrote "Extension Manager can install any JARs".
All JARs are extensions from Extension Manager point of view. Even if most of them are not specific to XWiki, the XWiki specific extension themself trigger a lot of dependencies among JARs which don't have anything to do with XWiki because they use those. Also XWiki is not just a wiki, it's actually a development platform.
Of course I can still prepare extension resolving artifacts and versions of
packages from Bintray via it's rest api, leaving space for future feature of searching when Bintray's API will be richer. The question is what's more usefull or needed.
If it does not support search then it's useless.
It does support search but in very simple way as described on design page: http://design.xwiki.org/xwiki/bin/view/Proposal/MoreextensionrepositoriesArt... searching goes only thorough names and descriptions.
This is alrea
So lets imagine that someone connects JCenter (Bintray) (with searching feature) in it's Xwiki instance, goes to Extension Magager and search for some extension putting e.g. LDAP. This will return a lot of results from JCenter (completely not needed), among which there'll be XWiki LDAP Authenticator extension - difficult to find.
One more element to keep in mind: there is priority support in repository sources so if you give a low priority to JCenter it's going to appear after the result of the search on http://extensions.xwiki.org.
I see two solutions: - not enabling searching at all for Bintray
Would be it totally useless IMO.
- enabling searching of Bintray but, adding in Extension Manager UI option to select from which repository search
Yes this is something we need to do anyway but it's out of scope for your GSOC so as you want.
WDYT?
Best, Krzysztof
2017-06-09 15:23 GMT+02:00 Thomas Mortagne <[email protected]>:
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 <
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
-- Thomas Mortagne
-- Thomas Mortagne
On Sun, Jun 11, 2017 at 6:49 PM, Thomas Mortagne <[email protected]> wrote:
On Sun, Jun 11, 2017 at 6:11 PM, Krzysiek Płachno <[email protected]> wrote:
Bintray JCenter may be connected even today using Maven Connector.
Maven Connector does not allow for searching, but in the case of JCenter that stores in the vast major non-xwiki extensions searching is unnecessary.
I don't think you understood the main goal of this project. The point is not to install XWiki stuff, Extension Manager can install any JARs and JCenter is full of useful JARs.
Yes - it seems that I misunderstood. The name of the project was "More extension repositories" and in my application I wrote only about extensions. But anyway it does not change a lot for my project - if as you wrote "Extension Manager can install any JARs".
All JARs are extensions from Extension Manager point of view. Even if most of them are not specific to XWiki, the XWiki specific extension themself trigger a lot of dependencies among JARs which don't have anything to do with XWiki because they use those. Also XWiki is not just a wiki, it's actually a development platform.
Of course I can still prepare extension resolving artifacts and versions of
packages from Bintray via it's rest api, leaving space for future feature of searching when Bintray's API will be richer. The question is what's more usefull or needed.
If it does not support search then it's useless.
It does support search but in very simple way as described on design page: http://design.xwiki.org/xwiki/bin/view/Proposal/MoreextensionrepositoriesArt... searching goes only thorough names and descriptions.
This is alrea
This is already nice IMO, I was not really expecting much more. Sure it won't cover the whole Extension Repository search API but it's OK.
So lets imagine that someone connects JCenter (Bintray) (with searching feature) in it's Xwiki instance, goes to Extension Magager and search for some extension putting e.g. LDAP. This will return a lot of results from JCenter (completely not needed), among which there'll be XWiki LDAP Authenticator extension - difficult to find.
One more element to keep in mind: there is priority support in repository sources so if you give a low priority to JCenter it's going to appear after the result of the search on http://extensions.xwiki.org.
I see two solutions: - not enabling searching at all for Bintray
Would be it totally useless IMO.
- enabling searching of Bintray but, adding in Extension Manager UI option to select from which repository search
Yes this is something we need to do anyway but it's out of scope for your GSOC so as you want.
WDYT?
Best, Krzysztof
2017-06-09 15:23 GMT+02:00 Thomas Mortagne <[email protected]>:
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 <
> 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
-- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne
Ok then. To sum up - at the moment I don't bother about Artifactory integration - I implement Bintray Connector as RepositoryManager and as Serchable - 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 - for the future I would be very 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.) Did I forget about sth important? Best, Krzysztof 2017-06-11 18:50 GMT+02:00 Thomas Mortagne <[email protected]>:
On Sun, Jun 11, 2017 at 6:49 PM, Thomas Mortagne <[email protected]> wrote:
On Sun, Jun 11, 2017 at 6:11 PM, Krzysiek Płachno <[email protected]> wrote:
Bintray JCenter may be connected even today using Maven Connector.
Maven Connector does not allow for searching, but in the case of JCenter that stores in the vast major non-xwiki extensions searching is unnecessary.
I don't think you understood the main goal of this project. The point is not to install XWiki stuff, Extension Manager can install any JARs and JCenter is full of useful JARs.
Yes - it seems that I misunderstood. The name of the project was "More extension repositories" and in my application I wrote only about extensions. But anyway it does not change a lot for my project - if as you wrote "Extension Manager can install any JARs".
All JARs are extensions from Extension Manager point of view. Even if most of them are not specific to XWiki, the XWiki specific extension themself trigger a lot of dependencies among JARs which don't have anything to do with XWiki because they use those. Also XWiki is not just a wiki, it's actually a development platform.
Of course I can still prepare extension resolving artifacts and
versions
of
packages from Bintray via it's rest api, leaving space for future feature of searching when Bintray's API will be richer. The question is what's more usefull or needed.
If it does not support search then it's useless.
It does support search but in very simple way as described on design page: http://design.xwiki.org/xwiki/bin/view/Proposal/ MoreextensionrepositoriesArtifactoryBintray#Investigationreport2 searching goes only thorough names and descriptions.
This is alrea
This is already nice IMO, I was not really expecting much more. Sure it won't cover the whole Extension Repository search API but it's OK.
So lets imagine that someone connects JCenter (Bintray) (with searching feature) in it's Xwiki instance, goes to Extension Magager and search
for
some extension putting e.g. LDAP. This will return a lot of results from JCenter (completely not needed), among which there'll be XWiki LDAP Authenticator extension - difficult to find.
One more element to keep in mind: there is priority support in repository sources so if you give a low priority to JCenter it's going to appear after the result of the search on http://extensions.xwiki.org.
I see two solutions: - not enabling searching at all for Bintray
Would be it totally useless IMO.
- enabling searching of Bintray but, adding in Extension Manager UI option to select from which repository search
Yes this is something we need to do anyway but it's out of scope for your GSOC so as you want.
WDYT?
Best, Krzysztof
2017-06-09 15:23 GMT+02:00 Thomas Mortagne <
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 <
> >> 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
-- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne
On Sun, Jun 11, 2017 at 10:53 PM, Krzysiek Płachno <[email protected]> wrote:
Ok then.
To sum up - at the moment I don't bother about Artifactory integration - I implement Bintray Connector as RepositoryManager and as Serchable
- 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
Or as dependency of a more XWiki oriented extesion too. Most extension on http://extensions.xwiki.org depends on JARs located on Maven Central that don't have anything to do with XWiki.
- for the future I would be very 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.)
Definitely.
Did I forget about sth important?
Sounds good :)
Best, Krzysztof
2017-06-11 18:50 GMT+02:00 Thomas Mortagne <[email protected]>:
On Sun, Jun 11, 2017 at 6:49 PM, Thomas Mortagne <[email protected]> wrote:
On Sun, Jun 11, 2017 at 6:11 PM, Krzysiek Płachno <[email protected]> wrote:
Bintray JCenter may be connected even today using Maven Connector.
Maven Connector does not allow for searching, but in the case of JCenter that stores in the vast major non-xwiki extensions searching is unnecessary.
I don't think you understood the main goal of this project. The point is not to install XWiki stuff, Extension Manager can install any JARs and JCenter is full of useful JARs.
Yes - it seems that I misunderstood. The name of the project was "More extension repositories" and in my application I wrote only about extensions. But anyway it does not change a lot for my project - if as you wrote "Extension Manager can install any JARs".
All JARs are extensions from Extension Manager point of view. Even if most of them are not specific to XWiki, the XWiki specific extension themself trigger a lot of dependencies among JARs which don't have anything to do with XWiki because they use those. Also XWiki is not just a wiki, it's actually a development platform.
Of course I can still prepare extension resolving artifacts and
versions
of
packages from Bintray via it's rest api, leaving space for future feature of searching when Bintray's API will be richer. The question is what's more usefull or needed.
If it does not support search then it's useless.
It does support search but in very simple way as described on design page: http://design.xwiki.org/xwiki/bin/view/Proposal/ MoreextensionrepositoriesArtifactoryBintray#Investigationreport2 searching goes only thorough names and descriptions.
This is alrea
This is already nice IMO, I was not really expecting much more. Sure it won't cover the whole Extension Repository search API but it's OK.
So lets imagine that someone connects JCenter (Bintray) (with searching feature) in it's Xwiki instance, goes to Extension Magager and search
for
some extension putting e.g. LDAP. This will return a lot of results from JCenter (completely not needed), among which there'll be XWiki LDAP Authenticator extension - difficult to find.
One more element to keep in mind: there is priority support in repository sources so if you give a low priority to JCenter it's going to appear after the result of the search on http://extensions.xwiki.org.
I see two solutions: - not enabling searching at all for Bintray
Would be it totally useless IMO.
- enabling searching of Bintray but, adding in Extension Manager UI option to select from which repository search
Yes this is something we need to do anyway but it's out of scope for your GSOC so as you want.
WDYT?
Best, Krzysztof
2017-06-09 15:23 GMT+02:00 Thomas Mortagne <
> 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 <
> > > >> 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 >
-- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne
Ehhhh... This bintray API and architecture approach is definitely over-complicated. And they do not provide documentation and explanation for the most fundamental things that should be written at the begging of each type of documentation, so to have answers for basic questions it's needed to figure it out on your own. I updated design page - I hope that it's for last time before I will be able to release something working. http://design.xwiki.org/xwiki/bin/view/Proposal/MoreextensionrepositoriesArt... 2017-06-12 9:23 GMT+02:00 Thomas Mortagne <[email protected]>:
On Sun, Jun 11, 2017 at 10:53 PM, Krzysiek Płachno <[email protected]> wrote:
Ok then.
To sum up - at the moment I don't bother about Artifactory integration - I implement Bintray Connector as RepositoryManager and as Serchable
- 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
Or as dependency of a more XWiki oriented extesion too. Most extension on http://extensions.xwiki.org depends on JARs located on Maven Central that don't have anything to do with XWiki.
- for the future I would be very 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.)
Definitely.
Did I forget about sth important?
Sounds good :)
Best, Krzysztof
2017-06-11 18:50 GMT+02:00 Thomas Mortagne <[email protected]>:
On Sun, Jun 11, 2017 at 6:49 PM, Thomas Mortagne <[email protected]> wrote:
On Sun, Jun 11, 2017 at 6:11 PM, Krzysiek Płachno <[email protected]> wrote:
> Bintray JCenter may be connected even today using Maven Connector. > > Maven Connector does not allow for searching, but in the case of JCenter > that stores in the vast major non-xwiki extensions searching is > unnecessary.
I don't think you understood the main goal of this project. The
point
is not to install XWiki stuff, Extension Manager can install any JARs and JCenter is full of useful JARs.
Yes - it seems that I misunderstood. The name of the project was "More extension repositories" and in my application I wrote only about extensions. But anyway it does not change a lot for my project - if as you wrote "Extension Manager can install any JARs".
All JARs are extensions from Extension Manager point of view. Even if most of them are not specific to XWiki, the XWiki specific extension themself trigger a lot of dependencies among JARs which don't have anything to do with XWiki because they use those. Also XWiki is not just a wiki, it's actually a development platform.
Of course I can still prepare extension resolving artifacts and
versions
of > packages from Bintray via it's rest api, leaving space for future feature > of searching when Bintray's API will be richer. The question is what's more > usefull or needed.
If it does not support search then it's useless.
It does support search but in very simple way as described on design page: http://design.xwiki.org/xwiki/bin/view/Proposal/ MoreextensionrepositoriesArtifactoryBintray#Investigationreport2 searching goes only thorough names and descriptions.
This is alrea
This is already nice IMO, I was not really expecting much more. Sure it won't cover the whole Extension Repository search API but it's OK.
So lets imagine that someone connects JCenter (Bintray) (with
searching
feature) in it's Xwiki instance, goes to Extension Magager and search for some extension putting e.g. LDAP. This will return a lot of results from JCenter (completely not needed), among which there'll be XWiki LDAP Authenticator extension - difficult to find.
One more element to keep in mind: there is priority support in repository sources so if you give a low priority to JCenter it's going to appear after the result of the search on http://extensions.xwiki.org.
I see two solutions: - not enabling searching at all for Bintray
Would be it totally useless IMO.
- enabling searching of Bintray but, adding in Extension Manager UI option to select from which repository search
Yes this is something we need to do anyway but it's out of scope for your GSOC so as you want.
WDYT?
> > Best, > Krzysztof > > 2017-06-09 15:23 GMT+02:00 Thomas Mortagne <
> >> 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 >>
-- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne
-- Thomas Mortagne
participants (2)
-
Krzysiek Płachno -
Thomas Mortagne