HI! I believe many may have set up tooling seetings, pipelines and are working git-forks+branches using the current directory structure of CKM mirror, so it would be quite disruptive to rearrange directory structure.
Are there any drawbacks at all with the alternative idea to just start another parallel sibling Github-repo (named “CKM-mirror2” or similar) with exactly the same directory structure as the current CKM-mirror , but with the difference that all content is based on ADL2 instead of ADL 1.4? I believe most organisations will use either ADL1.4 or ADL2 for any specific modeling session/task, with two repos you just pick the one you prefer for the session/task at hand.
2 Likes
That’s the obviously better version of what I suggested 
Yes, I would not want to rearrange the current directory structure without giving it a lot of thought first for the reason Erik has given.
Regarding one or two repositories: I would much prefer to have the CKM export in one git repository. Use cases will differ and I guess you could easily point to the path within a git repository if required.
Could you elaborate a bit on why one repo would be prefrerable to two? (I’m just curious and trying to understand.)
Remember that we are now discussing a complete converted copy of all the ADL1.4 assets turned into ADL2 variants.
The same effect could be achieved by having and ADL1.4 to ADL2 converter run on a server that is triggered by a CKM-mirror webhook, and performs the conversion and commits the changes to a CKM-ADL2-mirror. The Archie code to do that (or even my old Eiffel code) could be built as a command-line tool to do only that, so probably not that hard.
But I would have thought that if the ADL2 conversion is running routinely inside CKM anyway, a second commit to another repo would not be problematic.
To me it seems the most flexible and also easiest approach, just take what you need.
If someone really needs an adl2 only repo because a downstream tool cannot deal with it otherwise: I would imagine that a trigger that simply copies the adl2 directory to a separate repository would be a lot easier to implement than doing the conversion as well outside ckm: One problem with doing the conversion outside CKM is the conversion log which you need to make consistent decisions across the archetype revisions about synthesised node ids.
Be careful that the archie algo makes arbitrary assumptions when converting. (Adding at codes in 9000 range).
so different algorithms for conversion probably result in different archetypes with different paths. This is a potential nightmare.
For now I suggest using archie only for (CKM) conversions. And ideally we specify the algorithm in such a way that the results for any conversion are equal.
1 Like
@sebastian.garde’s suggestion of triggering a partial (ADL-version specific) copy sounds excellent, then all conversions are made by the CKM and the risks described by @joostholslag above can be handled there in one place in a more controlled manner. So what about something like this:
- CKM-mirror will contain the mix suggested by @sebastian.garde (new directories added and exsisting ones not changed)
- CKM-mirror2 could contain only ADL2 variants
- CKM-mirror1 could contain only ADL1.4 variants
For tools (and pipelines) that read the content of all subfolders under a specific root, either the CKM-mirror1 or CKM-mirror2 can be chosen to work from (depending on your version preferences) in order to avoid getting confused by two instances of every archetype.
3 Likes
Hi all,
just to confirm, AD supports ADL2.
It might be a bit rough over some edges, but you can import, edit, create ADL2 archetypes.
2 Likes
