openCAESAR needs a better way to manage projects

[mprather]

openCAESAR projects are very difficult to manage. There is not a single location where a developer can go to determine what the project is comprised of. This makes it difficult for new developers to understand how the tooling works and the minimum requirements to get their project up and running. Once a project is alive, refactoring the project is incredibly difficult because information is not in a single location.

openCAESAR needs to consider using a single source of truth for project configuration. This is akin to CMakeLists.txt, Visual Studio project files, or generally any config file that most modern frameworks define and utilize. The current openCAESAR methodology has the following major issues:

• build.gradle is effectively overused and abused. The gradle file has most but not all of the information that determines what is used or not. More importantly, though, it does not explicitly list what the project contains. Further, the chaining of what is effectively duplicate information from task to task makes it really easy to break the chain, project restructuring difficult, and very easy to stomp on other unused features.

• There is an awkward dependency on catalog.xml in the root folder as well. The information in the catalog.xml file can force the openCAESAR tasks to ingest data for processing even though the files that are picked are never used within the project. This behavior absolutely wreaks havoc when restructuring a project. There are also documented catalog.xml issues when projects use other openCAESAR projects as submodules.

I would like to suggest the following idea:

1. There needs to be a configuration file where all

   • project properties are defined
   • contains a list of project files

2. Build.gradle needs to reference the configuration file. This allows rapid change of locations, namespaces, etc. The build.gradle should never change because the contents of the project have changed.

3. openCAESAR tasks needs to be updated to work with this new style of project management

4. In build.gradle (and wherever appropriate), a clear set of interface methods needs to be defined for integration with the Rosetta functionality.

The ultimate goal is to have a build.gradle that never changes, unless you are power user trying to adjust the build process. Otherwise, my build.gradle file looks like yours.

Why is this important and useful?

• This will help reduce the cost from a learning and maintenance standpoint.
• A clear break between project management and build customization will help both new users and power users
• Project refactoring (changing namespaces, file names, folders) will become easier
• The more info that can be gleaned from a configuration file, the better the downstream tooling will become.
• Duplicate information in build.gradle will no longer exist
• Reduce the creation of ancillary files that are needed but could be autogenerated based on the config file

Here's a sample configuration file to help illustrate the ideas presented in this discussion. I am using a yaml format to keep things simple (this is not a recommendation for actual implementation).

Project:
- Name: MyName                      # Used for publishing scenarios?
- Version: 1.1                      # Used for publishing scenarios?
- UseBuiltInFuseki: true/false      # Allow users to specify whether to use an external fuseki server
- FusekiName: my-demo               # Use the fuseki properties to auto-gen a fuskeki.ttl if using built-in

Files:                              # Define full list of files, use this info to create an auto-generated catalog.xml
- src/oml/acs/bundle.oml
- src/oml/acs/dkp.oml
- src/oml/acs/imu.oml
- src/oml/heat-pump/heat-pump.oml
- src/oml/heat-pump/heat-pump-bundle.oml

[melaasar]

Good suggestion but just checking, have you considered using gradle.properties file to externalize those settings?

[mprather]

Yes but it's insufficient and can't address the breadth of issues that could be solved if the information was in a single place and everything else was managed around that concept.