[FOLIO-1727] SPIKE: select particular implementation when interface is provided by multiple modules Created: 22/Jan/19 Updated: 03/Jun/20 |
|
| Status: | Open |
| Project: | FOLIO |
| Components: | None |
| Affects versions: | None |
| Fix versions: | None |
| Type: | Task | Priority: | P3 |
| Reporter: | John Malconian | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 0 |
| Labels: | ci, platform-backlog | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Issue links: |
|
||||||||||||||||||||
| Sprint: | |||||||||||||||||||||
| Development Team: | Core: Platform | ||||||||||||||||||||
| Description |
|
In certain cases we may have multiple modules provide the same interface and there's no standard way to address it. |
| Comments |
| Comment by John Malconian [ 22/Jan/19 ] |
|
We'll start with updating the hosted folio-testing environment first and wait for the go ahead from Carole Godfrey before updating the folio-snapshot environment. Since the two modules share the same interface versions, the java-based module on master needs to be a higher version than the current version of the ruby-based module in order for Okapi's interface dependency resolution mechanism to resolve to the java-based module. |
| Comment by Carole Godfrey [ 22/Jan/19 ] |
|
Of note – users of mod-kb-ebsco-java module require permission kb-ebsco.all to access needed backend functionality |
| Comment by John Malconian [ 22/Jan/19 ] |
|
mod-kb-ebsco is at version of 1.0.2-SNAPSHOT.157 on master according folio-registry. The latest release version is v1.1.0. mod-kb-ebsco-java is currently at 0.1.0-SNAPSHOT. There is currently no MD for mod-kb-ebsco-java posted at folio-registry. In order enable mod-kb-ebsco-java on folio-testing, I'll need to manually post a MD for v0.1.0-SNAPSHOT to folio-registry. When we are ready to enable mod-kb-ebsco-java on folio-snapshot, we need to merge a mod-kb-ebsco-java PR that enables posting the MD to the registry as well as increment the version to v2.0.0-SNAPSHOT. Wayne Schneider does this sound right to you? I guess I'll test the Okapi install endpoint to see which modules are resolved before implementing any changes. |
| Comment by Wayne Schneider [ 22/Jan/19 ] |
|
John Malconian this sounds right, but why do we need to jump to v2.0.0? Did you mean v0.2.0? |
| Comment by John Malconian [ 22/Jan/19 ] |
|
Carole Godfrey created https://github.com/folio-org/mod-kb-ebsco-java/pull/91 |
| Comment by John Malconian [ 22/Jan/19 ] |
|
Wayne Schneider I did mean 2.0.0. I wanted to ensure Okapi's install endpoint grabbed the latest version of the module (both modules have the same interface and interface version). Now that I think about it, however, I don't think this will guarantee anything since they different modules. So, I guess I'm not sure what Okapi will do with different modules with the same interface/version and if it will be consistent. |
| Comment by Wayne Schneider [ 22/Jan/19 ] |
|
John Malconian judging from this comment on
|
| Comment by John Malconian [ 23/Jan/19 ] |
|
Hmm. Bummer. In the case of
|
| Comment by Wayne Schneider [ 23/Jan/19 ] |
|
Doesn't the build task get the module descriptor from the registry with a GET request even if it doesn't do a pull? (I'm pretty sure it does). Could we add mod-kb-ebsco-java as an "extra" module (as with mod-codex-*), so that it's posted to Okapi as part of the initial dependency resolution request? |
| Comment by John Malconian [ 23/Jan/19 ] |
|
yeah, you're right. I guess we could add as an extra module although that seems a bit hacky. Probably the likeliest solution at this point. |
| Comment by Adam Dickmeiss [ 29/Jan/19 ] |
|
I suppose even if Okapi had a "replaces" feature, like Debian (see
|
| Comment by Hongwei Ji [ 29/Jan/19 ] |
|
How about codex? We have different modules implementing the same codex interface and version. |
| Comment by John Malconian [ 29/Jan/19 ] |
|
Hongwei Ji I don't think that any modules specify codex interfaces as a dependency, do they? We typically declare the codex modules explicitly when installing. |
| Comment by Hongwei Ji [ 29/Jan/19 ] |
|
Does UI module count? https://github.com/folio-org/ui-search/blob/master/package.json#L29 |
| Comment by Jakub Skoczen [ 29/Jan/19 ] |
|
Hongwei Ji Adam Dickmeiss John Malconian Guys, I renamed this to represent the spike about finding the general solution. I cloned the original issue an linked it here. Question 1: do we need a general solution in order to complete
Question 2: it sounds like what we are after is the ability to control what implementation is used. Maybe we could add this to the MD? |
| Comment by Wayne Schneider [ 29/Jan/19 ] |
|
Jakub Skoczen – are you suggesting that the MD contain the "replaces" functionality suggested by Adam Dickmeiss? There is still the use case proposed by Hongwei Ji, that a multi-tenant shared environment could offer multiple implementations of an interface as legitimate alternatives, not as a replacement (also not addressed by Adam Dickmeiss's proposal to have separate module descriptor registries). |
| Comment by Jakub Skoczen [ 29/Jan/19 ] |
|
John Malconian Wayne Schneider Adam Dickmeiss Hongwei Ji Copy-paste what I wrote on slack: I think there are two use cases here: |
| Comment by Hongwei Ji [ 29/Jan/19 ] |
|
I see the second feature is very much needed, and it also exists already as folks pointed out. For the first feature, I feel it blurs the line a bit between module and interface. From a practical perspective, feature 2 can do what feature 1 needs. |
| Comment by Adam Dickmeiss [ 30/Jan/19 ] |
|
Replaces feature added to okapi -
|