Hello, I'm forwarding you more information about the migration of ODL based projects to a more lightweight framework - about removing the OSGi dependencies. Two weeks ago I sent this email to the SDNC mailing-list and now I'm reaching to the wider audience, because we would like to hear your opinions on this.
Original email: I would like to propose a way how to remove dependencies on the OSGi Framework and Karaf from the CCSDK project while still maintaining same ODL services like Restconf. It is done by integrating the CCSDK with the lighty.io (https://github.com/PantheonTechnologies/lighty-core). We would like to see your feedback about these changes. In our opinion the result is much smaller, more nimble package, which is also easier to grasp by developers and easier to develop with and debug as opposed to with the Karaf version. We would like to present the idea, concept, and proposal on your regular weekly meeting next week. More info regarding the first implementation draft below. Links to gerrit changes: core - https://gerrit.onap.org/r/c/ccsdk/sli/core/+/84048 adaptors - https://gerrit.onap.org/r/c/ccsdk/sli/adaptors/+/84049 northbound - https://gerrit.onap.org/r/c/ccsdk/sli/northbound/+/84090 plugins - https://gerrit.onap.org/r/c/ccsdk/sli/plugins/+/84202 distribution - https://gerrit.onap.org/r/c/ccsdk/distribution/+/84050 lighty.io is basically a toolkit that utilizes main OpenDaylight components, which are available as a set of libraries. It removes the dependency on the OSGi framework Apache Karaf together with the Apache Aries Blueprint dependency injection from the OpenDaylight. Instead of these frameworks the lighty.io uses just plain java - for example good old main method for running the application (.jar file) or plain java constructors to inject necessary instances. In fact, the resulting app is easier to integrate with any modern and concurrent Java frameworks of your choice (Spring e.g.). Biggest benefit for the developers is in my opinion much faster and easier development and debugging since they do not have to deal with issues coming from the OSGi frameworks and most of the work is done in java (not the xml configuration files). In addition, building the project and starting/stopping the application is faster and with smaller footprint and the startup is deterministic. Another great thing is that lighty.io is open-source so you can see exactly how it works (together with a few examples in GitHub repository). Official lighty.io web-page - https://lighty.io<https://lighty.io/> GitHub repository - https://github.com/PantheonTechnologies/lighty-core I have created so called lighty.io modules (implementations of the LightyModule interface) for parts of the CCSDK project that were exposing services using blueprint. These services are started in the lighty.io modules and can be accessed via get methods of the respective module (instead of Blueprint DI). Every repository has one "aggregator" lighty.io module that groups all other modules from that repository. This allows to start/stop all modules from one repository at once just with a few lines of code. Repository distribution contains artifact that creates distribution of the CCSDK lighty.io application packaged as a zip. It contains CCSDK lighty.io application jar file and necessary libraries. This zip distribution is then used in the docker image and the docker-compose file. Those are very similar to the original ones. For example in the docker-compose file is changed only the docker image of the CCSDK. For more information about this see the README.md file located in the lighty/docs directory in the distribution repository. If you want to see it in action try the example described in the mentioned README.md file. During the integration I encountered some problems. Mostly with hard dependencies on the OSGi libraries, which cannot be used together with the lighty.io (since we are getting rid of them). Because of this I had to create copies of some classes and remove these dependencies from them. Some of them can be fixed in the original code easily and some of them are harder. So far I did not touch the original code. Most of the code duplicity (copied classes) can be fixed by creating interfaces for some classes that have the OGSi dependencies (if you want I can elaborate this in the next email). Another problem was for example cyclic dependency between the core repository and the adaptors repository - one class from the core repository needs an instance from the adaptors repository but the adaptors repository is dependent on the instances from the core repository. Please, if you have any questions or feedback just reply to my email. We would like to get feedback from the community. Regards Samuel -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18070): https://lists.onap.org/g/onap-discuss/message/18070 Mute This Topic: https://lists.onap.org/mt/32478122/21656 Mute #ccsdk: https://lists.onap.org/mk?hashtag=ccsdk&subid=2740164 Group Owner: [email protected] Unsubscribe: https://lists.onap.org/g/onap-discuss/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
