As suggested by @mkllnk in datafoodconsortium/connector-typescript#14 (comment), I think we should add the data-model-uml repository as a Git submodule here in the codegen repo. This would bring more consistency, transparency, and overall ease to the process of upgrading ontologies here in the 3 main implementations. Because separate branches and tags here in the codegen can be based on a separate commits in the data model, different versions and builds can still be pinned to different models, and that will always be traceable in the git history for each an every commit.
I've started a branch and tested it out, and it works quite well! I can open a PR for it right away, but I think we should be a little careful to how contributors pull those changes in. For one thing, it will require that anyone running Acceleo builds with the model directory outside of the /connector-codegen directory will need to update then run configuration in Eclipse. Far more importantly, however, anyone who was running builds with the model directory inside the codegen directory (as /connector-codegen/data-model-uml) will need to be careful to move that directory out of the codegen repository before pulling this PR's changes into the codegen repository. A necessary component of this was to remove /data-model-uml from the .gitignore so it can be referenced by Git as a submodule under the same name. I'm not 💯 sure what would happen if you tried to pull the submodule commits with the other clone of the data model already at that path – I would hope that Git would simply error out then abort the pull, or just require that merge conflicts be merged before completing the pull – but it seems at least possible that it could cause any uncommitted changes could be lost or general mayhem to ensue.
So that's a bit of a painpoint, but I still think entirely worth it. Once everyone makes the switch, there won't be any more issues problems, even if you switch back to an older branch before the submodule was introduced – I tested that out and it just ignores the directory while you're on the older branch, then goes back to tracking it without issue when you switch to a newer branch with the submodule.
The really nice thing about this, I think, is that it will allow for the connector-codegen repository itself to become a submodule of the separate library repositories, like connector-typescript and connector-ruby, if we choose too. That sounds like even more madness, I know, but it seems totally fitting since it only mirrors the dependency chain (model -> codegen -> library) that's already fixed in place regardless. The huge benefit at that point is the entire build process can potentially be automated, so for instance when the connector-typescript library pulls the changes from the latest connector-codegen release (or just any particular branch you wish to build from), then it comes already pegged to a specific branch/tag/commit of the data-model-uml repository. It's all daisy-chained together perfectly that way, because whenever a parent directory pulls changes for a submodule (e.g., cd connector-codegen/data-model-uml && git pull origin next), that pull is version-controlled, too, and the parent directory has to commit it to its own history (e.g., cd .. && git add ./data-model-uml/ && git commit -m "Update data-model-uml to v3.1.0"), with the commit hash from the respective submodule automatically included in the parent's diffs.
Add a few GitHub actions into the mix and you have a pretty nice automation pipeline, I think.
As suggested by @mkllnk in datafoodconsortium/connector-typescript#14 (comment), I think we should add the
data-model-umlrepository as a Git submodule here in the codegen repo. This would bring more consistency, transparency, and overall ease to the process of upgrading ontologies here in the 3 main implementations. Because separate branches and tags here in the codegen can be based on a separate commits in the data model, different versions and builds can still be pinned to different models, and that will always be traceable in the git history for each an every commit.I've started a branch and tested it out, and it works quite well! I can open a PR for it right away, but I think we should be a little careful to how contributors pull those changes in. For one thing, it will require that anyone running Acceleo builds with the model directory outside of the
/connector-codegendirectory will need to update then run configuration in Eclipse. Far more importantly, however, anyone who was running builds with the model directory inside the codegen directory (as/connector-codegen/data-model-uml) will need to be careful to move that directory out of the codegen repository before pulling this PR's changes into the codegen repository. A necessary component of this was to remove/data-model-umlfrom the.gitignoreso it can be referenced by Git as a submodule under the same name. I'm not 💯 sure what would happen if you tried to pull the submodule commits with the other clone of the data model already at that path – I would hope that Git would simply error out then abort the pull, or just require that merge conflicts be merged before completing the pull – but it seems at least possible that it could cause any uncommitted changes could be lost or general mayhem to ensue.So that's a bit of a painpoint, but I still think entirely worth it. Once everyone makes the switch, there won't be any more issues problems, even if you switch back to an older branch before the submodule was introduced – I tested that out and it just ignores the directory while you're on the older branch, then goes back to tracking it without issue when you switch to a newer branch with the submodule.
The really nice thing about this, I think, is that it will allow for the
connector-codegenrepository itself to become a submodule of the separate library repositories, likeconnector-typescriptandconnector-ruby, if we choose too. That sounds like even more madness, I know, but it seems totally fitting since it only mirrors the dependency chain (model -> codegen -> library) that's already fixed in place regardless. The huge benefit at that point is the entire build process can potentially be automated, so for instance when theconnector-typescriptlibrary pulls the changes from the latestconnector-codegenrelease (or just any particular branch you wish to build from), then it comes already pegged to a specific branch/tag/commit of thedata-model-umlrepository. It's all daisy-chained together perfectly that way, because whenever a parent directory pulls changes for a submodule (e.g.,cd connector-codegen/data-model-uml && git pull origin next), thatpullis version-controlled, too, and the parent directory has to commit it to its own history (e.g.,cd .. && git add ./data-model-uml/ && git commit -m "Update data-model-uml to v3.1.0"), with the commit hash from the respective submodule automatically included in the parent's diffs.Add a few GitHub actions into the mix and you have a pretty nice automation pipeline, I think.