IMO: (Almost) Every project based on ODL needs to compile its YANG models. I see no reason to create separate repository for just one project. In case you experience long build times you can use maven settings to make it better - for example -Pq.
Thank you Ivan for your relevant comment. Let me give you an additional explanation to clarify this point:
In fact, in the transportPCE project, we have two kinds of yang models:
those developed and managed by the transportpce-dev team (under transportpce/api): they allow us to develop all our internal module APIs, our internal POJO data structure and so on. These models will not move outside the project, because they evolve with the evolution of the transportpce code and are totally under our control.
those developed and released by external communities outside ODL (currently, OpenROADM MSA and ONF-TAPI, respectively under transportpce/ordmodels and transportpce/tapimodels, and in the short term openconfig). These "official" models are never modified within the TransportPCE project (or, exceptionally very rarely, temporarily, for a very good reason linked to a strong bug somewhere...). This request is only for those models maintained outside of the ODL community.
Ideally, I think it would be preferable for this new project to be a managed one. This would make it possible to detect any problem related to these models more quickly during the development step of some kernel projects such as yangtools or even mdsal. Now, we remain open on this point and we will adapt.
9 Comments
Ivan Hrasko
IMO: (Almost) Every project based on ODL needs to compile its YANG models. I see no reason to create separate repository for just one project. In case you experience long build times you can use maven settings to make it better - for example -Pq.
Gilles Thouenon
Thank you Ivan for your relevant comment. Let me give you an additional explanation to clarify this point:
In fact, in the transportPCE project, we have two kinds of yang models:
I hope this will help you.
Ivan Hrasko
Is that new project going to be self-managed one?
Gilles Thouenon
Ideally, I think it would be preferable for this new project to be a managed one. This would make it possible to detect any problem related to these models more quickly during the development step of some kernel projects such as yangtools or even mdsal. Now, we remain open on this point and we will adapt.
Ivan Hrasko
yangtools and mdsal are MRI. I think that chances to adopt their versions are the same for managed and self-managed projects.
Ivan Hrasko
In case transport-pce is going to be managed then it's OK.
Guillaume Lambert
That's what we agreed a few months ago.
Normally this survey has been configured to let the possibility to change your vote.
Ivan Hrasko
TransportPCE verify job takes 20 mins only. I see no need to split this project.
Ivan Hrasko
OK, changed opinion during TSC.