Project

General

Profile

Feature #9639

centralized name management (and conversion) OR jar based resolution

Added by Greg Shah over 1 year ago. Updated 11 months ago.

Status:
New
Priority:
Normal
Assignee:
-
Target version:
-
Start date:
Due date:
% Done:

0%

billable:
No
vendor_id:
GCD
case_num:
version_reported:
version_resolved:
reviewer:
production:
No
env_name:
topics:

Related issues

Related to Conversion Tools - Feature #9638: resolve OO dependencies during parsing using annotations in already converted classes WIP
Related to Conversion Tools - Feature #10458: stable and deterministic name generation during app-by-app conversion Rejected
Related to Conversion Tools - Feature #7169: drive conversion order using user-specified dependencies WIP
Related to Conversion Tools - Feature #11404: Implement annotation-based resolution for database dependencies. WIP
Related to Conversion Tools - Feature #6320: sharded schemata WIP

History

#1 Updated by Greg Shah over 1 year ago

  • Subject changed from centralized name management (and conversion) to centralized name management (and conversion) OR jar based resolution

In #7077, a customer has prototyped the implementation of temp-table DMO conversion split across different conversion runs. One of the biggest issues is how names are resolved (and the detection/honoring of already existing converted entities).

We are implementing full support for an "app by app" conversion process where sections of an application can be independently developed and converted but the full result must be cleanly merged together into a single installation. As part of that approach, we may need some kind of centralized name processing and/or some ability to inspect jars of converted application code to satisfy/resolve converted names.

Using jar files to read annotations from converted code is the preferred approach. Ensuring stable and consistent converted names is a key objective here and to the extent that it is not possible with access to jars alone, then we may need a centralized service for naming (and other state?).

#2 Updated by Greg Shah over 1 year ago

  • Related to Feature #9638: resolve OO dependencies during parsing using annotations in already converted classes added

#4 Updated by Greg Shah 11 months ago

  • Related to Feature #10458: stable and deterministic name generation during app-by-app conversion added

#5 Updated by Greg Shah 11 months ago

  • Related to Feature #7169: drive conversion order using user-specified dependencies added

#6 Updated by Greg Shah 11 months ago

We need to ensure that the names we generate (classes, methods, data members...) are stable and deterministic. This means the same names should be calculated regardless of:

  • Conversion of a project:
    • as a single batch with all files done at once
    • as a set of mutually exclusive "apps", each converted separately in an explicitly defined dependency order ("app-by-app" mode)
  • In incremental mode as a single batch or as app-by-app.
  • Single or multithreaded conversion.

A big part of this solution is to ensure that we store enough conversion and legacy name state in Java annotations that we can populate our conversion naming data structures by reading those annotations from the app dependencies as represented by binary jar files that are available at conversion time. During a single batch conversion, such an approach is not needed because all of the names are being calculated in the current process. I expect this to be a solution for things like temp-table DMO names, class names and overloaded 4GL OO method names and so forth. Some of this work might be done in #7169.

See #10420-6 for a description of how a customer built their own app-by-app name solution for TT DMOs by using a centralized database.

#7 Updated by Greg Shah 3 months ago

  • Related to Feature #11404: Implement annotation-based resolution for database dependencies. added

#8 Updated by Greg Shah 3 months ago

Also available in: Atom PDF