Project

General

Profile

Feature #10459

migrate all project configuration into a single jSON configuration file

Added by Greg Shah 11 months 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:

History

#1 Updated by Greg Shah 11 months ago

The current approach to conversion project configuration is a frankenstein monster which we have pieced together over time without regard to consistency or managability. Consider that we have the following sources of configuration:

  • cfg/p2j.cfg.xml
  • cfg/codenames.xml
  • cfg/datanames.xml
  • cfg/ehcache.xml
  • cfg/logging.properties
  • cfg/matchlist.xml
  • cfg/rootlist.xml
  • build.properties
  • *.input.* (prepare script input)
  • */directory.hints
  • */<program_name>.hints
  • */<program_name>.ext-hints

And I'm probably forgetting some files. If so, please post here.

I see no value in having all these separate ways to configure our conversion. It is messy and fragile and confusing. The idea here is to rework the places in FWD which read these configuration sources to read instead from a single one-json-to-rule-them-all input. We will design the various cfg as needed to replace the existing files. The starting point is the p2j.cfg.xml structure which would be translated into json but otherwise could largely stay the same. Then each other input would be merged into this structure depending on the specific situational requirements.

This will be a breaking change, so we will have to carefully coordinate the project updates when this merges. I don't want to support the old and new ways simultaneously.

#2 Updated by Constantin Asofiei 11 months ago

There are also schema hint files.

We should also have a tool to gather all these input files and generate the .json file.

#3 Updated by Roger Borrello 11 months ago

The "new" hotel method generates a JSON based upon the responses to the prompts. This JSON is also made available in the deploy/server so prepare_dir.sh can drive the runtime configuration. Most projects I have touched utilize the given prepare_dir.sh as a starting point for all the specific application requirements, and if you compare one project's version to another, they are largely the same model for building out the runtime configuration.

Should we also have the conversion JSON be a starting point for the runtime? I believe Constantin is also familiar with how "out of control" it can get, with a much simpler cut-down JSON that only makes necessary substitutions once the base configuration is created.

It would be a good idea to design all the way down to the runtime configuration as well.

#4 Updated by Greg Shah 11 months ago

The "new" hotel method generates a JSON based upon the responses to the prompts.

We will want to invert that. I don't want us to spend time on a shell based prompted UI. It is OK to assume that the values can be read from a common json cfg file.

With our IDE work, we will provide a UI to edit the configuration.

This JSON is also made available in the deploy/server so prepare_dir.sh can drive the runtime configuration. Most projects I have touched utilize the given prepare_dir.sh as a starting point for all the specific application requirements, and if you compare one project's version to another, they are largely the same model for building out the runtime configuration.

We will have to discuss the runtime requirements and how best to handle them.

Should we also have the conversion JSON be a starting point for the runtime?

Probably. Again, consider the IDE support which will need to be able to startup servers and clients for debugging/testing.

Also available in: Atom PDF