Repository Naming Convention

[tsvetlin]

Repositories should be named in strict pattern in order to be easily searchable, distinguishable and for transparency.

For this reason the following naming convention is proposed:

<type>-<programming language>-<technology>

type can have the following values:

• client-library
• client-skeleton
• client-examples
• core

programming language can have the following values:

• any programming language is supported

technology can have the following values:

• any technology is supported

Note: technology is optional. It is for distinguising purpose only. If multiple implementation of the same language exists or brand name eg. kalix. Multiple technologies can be listed

Example repository names following the convention:

core-java-spring
client-library-java-kalix
core-cpp
client-examples-java-spring
client-skeleton-java-spring

[jerkerdelsing]

Since we use the term application systems I suggest the following changes

• application-library or app-library
• applciation-skeleton or app-skeleton
• application-examples or app-examples
• core

We may even start to make use of the terminology micro-app.

This also indi

[emanuelpalm]

How would you represent a repository that contains only documentation?

[jerkerdelsing]

You mena like roadmap. Let it be named roadmap!

[emanuelpalm]

@jerkerdelsing @tsvetlin How do we proceed with this issue?

[BlackRose01]

Maybe as an example Eclipse Paho solved the problem like this paho.mqtt.c or paho.mqtt.golang. So the naming could be arrowhead.serviceregistry.java and arrowhead.common.java and I would remove the framework from the name because it is not necessary and make the title too long. I added a picture to show the dependency structure (not 100% correct I think) and maybe a good naming accoding to the paho structure.

Each rectangle demonstrates its own repository. The container is a general grouping of the repositories.

[jerkerdelsing]

I can see the following development

We will have Arrowhead core systems, some written in Java, GO, C++ and other languages Core systems are currently divided into Mandatory and Support core systems. With the growing number of Support core systems I propose that these should be divided into sub groups like e.g. Sub groups can be according to the stack I defined some time ago. It was agreed in Lubeck to use this stack for the web pages at www.arrowhead.eu/eclipse-arrowhead

As examples

• Libraries are here located under engineering tools
• Adaptors for interoperability is located under Interoperability.

Then we will start to have application systems. Here I think we again will need to provide a grouping to make it easier to brows and find interesting application systems. Long term search will be the only usable way. A grouping could be:

• Sensor systems
• Actuator systems
• Control systems
• ...

We will also start to see commercial systems which are Arrowhead compliant from companies like e.g. Jotne, BnearIT, REUSE, ...

We might end up in different structures for different groups of users in our community:

• Developers
• Solution architects
• Solution developers
• Solution operators
• Managers

First we need to decide if we will see different structures at different places or if we should strive for the same or similar structure at most places like GitHub, eclipse.org, arrowhead.eu/eclipse-arrowhead

[BlackRose01]

I think it will not be possible or very hard to structure the repositories to match all different groups and it is a huge expense for everyone. The names of the repository should be simple and easy so that people which are not part of the arrowhead universe understand the basic structure of it. Better is when you create a website which maps/visualize your stack (e.g. https://www.hivemq.com/developers/) to all groups and link to each repository.

[jerkerdelsing]

As indicated such web page is on its way. Anyhow the thinking on names have to be synchronised across the whole stack of users.