search

CNES / ccsdsmo-malc-stubgenerator

Stub Generator for CCSDS MAL C API
https://cnes.github.io/ccsdsmo-malc
MIT License
3 stars 2 forks source link

Repo to be merged to malc #13

Closed ochurlaud closed 5 years ago

ochurlaud commented 5 years ago

I intend to merge this repo in the malc one to reduce the number of repos. Before doing this I'd like to be sure you don't see a reason why it's a bad idea.

@gbonnefille

@freyssin

@lacourte

gbonnefille commented 5 years ago

As far as I know, there are two motivations to use two distincts repositories. The first one is the technology stack: one is raw C while other is a Java/Maven providing a plugin for an other tool. The second one is the (initial) motivation to consider malc as an independent low level layer. This component could be used without the codes generated by the generator.

IMHO, even if this increase the number of repositories, I feel it is cleaner/simpler to keep the repositories separated.

Eventually, a merge should be evaluated against the official generator. Such merge will certainly offer a transparent support for this plugin: less repo, less maintenance effort.

ochurlaud commented 5 years ago

@gbonnefille I quite value your argument I would have one other thought for merging the stub with its api: it is very unlikely that a développer implements MO Services without using a stub generator. Writing the full boil-plate code for each service and operation seems very repetitive and not that interessant.

Is that enough to merge them?. Maybe not. I am not sure

gbonnefille commented 5 years ago

@gbonnefille I quite value your argument I would have one other thought for merging the stub with its api: it is very unlikely that a développer implements MO Services without using a stub generator. Writing the full boil-plate code for each service and operation seems very repetitive and not that interessant.

I had the same thought during the initial meeting with @freyssin and @lacourte. I remember the motivation was to have a really low-level API in order to be able to create component like routers. Other thought: even the Java implementation use separated repositories.

If the motivation is to simplify the initial checkout, I would suggest to take a look at git submodule: adding a super-repository linking all needed components, at the expected commit. Such super-repository will be updated only when releasing a new version. It would be possible to link in this repository, all CNES' implementations (malc, mal-java, malgo) and eventually the related COTS (zeromq).

ochurlaud commented 5 years ago

For the time being, it will stay as it is.