Gang Fang's Blog

On why dependencies (version set in the Amazon world) should be updated frequently

I am working on a logic package which is dependent on a data model package requiring changes. I modified the data model and updated the retrieval logic accordingly. In order for the logic package to compile and build, I need to include the data model package in the same local workspace so that the logic package has can obtain the JAR of the updated data model within the workspace.

I use the version set (i.e., a bucket holding all dependencies needed by a package) for the logic package as the version set of the workspace, meaning the data model package will use the same version set. There are a couple of dependent packages of the data model package absent in the version set, hence I needed to fetch them into the version set from the parent version set on the cloud in Amazon dev eco-system.

This is where the problem occurred: the last merge from parent of this version set was done 8 months ago and there is a considerable gap between old code (i.e., the 8-month old snapshot) and the latest code. When I attempted to fetch needed packages into this version set, I got a bunch of Symbol not found errors when the dependencies of the needed packages were being built. The reason of these errors is that the merged in packages and their dependencies are fetched from the latest parent version set and therefore have the latest code, which, however, doesn’t exist in their dependencies (i.e., one more level down) in the 8-month out-of-date version, resulting in the Symbol not found errors. I tried merging in packages from the older snapshot of the parent version set instead of the latest but it still failed because the new packages brought in new code dependent on old packages that don’t support that new code. Another quirky solution I tried is using live version set for the workspace since the data model package’s primary workspace is live. But it didn’t work because the logic package dependent on some team-owned packages that aren’t shared in the companywide live version set.

So now the two ways out:

• Bring the version set to the latest, which means to resolve an inconsistency in dependencies that have always been around, which is why I didn’t do it in the first place.
• Change the data model package in a separate workspace and raise a CR. Then merge the data model package into the outdated version set so that it has the latest data model, facilitating the build of my logic package.
  • An unrelated pipeline auto-builds this data model package.

I will spend whole day tomorrow to merge from parent version set for the version set because it has to be done sooner or later. If it takes longer, I will consider the second option.