Update all Data-Import modules to the new RMB and JDK versions
RCA Group
Description
Environment
Potential Workaround
blocks
defines
is defined by
Checklist
hideTestRail: Results
Activity

Ann-Marie Breaux September 30, 2020 at 7:52 AM

Marc Johnson September 24, 2020 at 3:57 PM
In order to meet the release schedule, we need to start upgrading mod-inventory soon. How do we decide which team is going to do that work? Personally, I think that FoliJet are best placed to do that because they are most familiar with the libraries that need upgrading in unison with that change.
If core-functional need to do this work, please provide details on what library changes are needed.

Marc Johnson September 23, 2020 at 10:07 AM
I don’t see a problem using the SNAPSHOT versions of libraries in the SNAPSHOT version of mod-inventory.
As I understand it, snapshot dependencies are less stable (they are intended to be temporary and replaced in place), hence this increases the chances of an unstable build of mod-inventory. This happened recently in mod-inventory-storage which used a snapshot version of RAML Module Builder ( please correct me if I'm wrong) :-/
We have some problems with mod-inventory and our mod-source-record-storage-client. This client built by JDK 11 and doesn’t work correctly in mod-inventory with JDK8. If we release our libs it isn’t fixed this problem. My proposal is to update the mod-inventory to JDK11 and test all changes. Then we can release our libs and update the version to release one in mod-inventory. Next step should be release for mod-inventory.
Personally, I think that the libraries should be tested independently of use and released. However, given you are reluctant to release the libraries until they have been used in mod-inventory then ok, let's proceed with snapshot versions.
Given these conditions, it seems FoliJet have more context about the upgrade to JDK 11 (and Core Functional don't know what the appropriate versions of the libraries are). Might it be more appropriate for FoliJet to upgrade mod-inventory to JDK 11 in order to use the new library versions?
That way, once that testing is completed, the libraries can then be released and mod-inventory updated as soon as possible.
cc:

Kateryna Senchenko September 23, 2020 at 8:28 AM
Hi , ,
I created the necessary JIRA tickets. We can release LIQUTIL and MODPUBSUB, but we cannot yet release MODDICORE and MODSOURCE without and other stories that should be included in the upcoming release. data-import-processing-core and mod-source-record-storage (as well as other data-import modules) are upgraded to Java 11 and can be used as SNAPSHOT dependencies for mod-inventory. Once mod-inventory is upgraded to Java 11, we can finish our work on and related stories, then proceed with releases.
CC:

Oleksii Kuzminov September 23, 2020 at 8:17 AM
Hello . I don’t see a problem using the SNAPSHOT versions of libraries in the SNAPSHOT version of mod-inventory. We have some problems with mod-inventory and our mod-source-record-storage-client. This client built by JDK 11 and doesn’t work correctly in mod-inventory with JDK8. If we release our libs it isn’t fixed this problem. My proposal is to update the mod-inventory to JDK11 and test all changes. Then we can release our libs and update the version to release one in mod-inventory. Next step should be release for mod-invetory.
As I see order:
1. update JDK for mod-inventory
2. test changes
3. release for mod-srs mod-pubsub
4. update dependencies version to the release version
5. release mod-inventory
There is no sense to release our modules before mod-inventory JDK 11 update. It can't fix existing problems with code incompatibility
CC
Details
Details
Assignee

Reporter

Hi Changed this to an umbrella and created Closed tasks in each of the 5 backend modules for RMB and JDK upgrades, so that they could be linked to the proper release epics.