Time to add License Management to your Eclipse Product
Your Eclipse product is good enough to have license management, isn't it?
Learn how to define and control license checks and usage constraints for OSGi/RCP/IDE with Eclipse Passage
Your Eclipse product is good enough to have license management, isn't it?
Learn how to define and control license checks and usage constraints for OSGi/RCP/IDE with Eclipse Passage
Even when using a modular software framework such as OSGi to structure software projects, architects and programmers can quickly lose the overview of how all the bundles and features correlate with each other and how the services as the bundle's interfaces are provided and used. Surely, some project members know about these connections and have some mental model of what is happening in the system. Documentation and the manifest, feature, etc. files will eventually provide that information to the curious reader.
The OSGi Core Release 8 specification is coming soon. Included in the OSGi R8 Core specification is a new chapter called OSGi Connect. This talk will discuss the details of the OSGi Connect specification and give examples of how it can be used to enable OSGi technologies in a wide variety of environments, such as, jlink images, native-images and Android applications.
OSGi was originally concieved as a technology for deployment on the network edge, and in IoT situations its is a powerful and widely used technology. However, over time, it’s use has spread to the server too, and in this talk we will present and discuss a real world architecture where OSGi is used everywhere from the edge to the enterprise to deliver a globally distributed solution for a major customer.
Semantic Versioning is the current standard for supporting software changes over time. It also an integral part of the OSGi platform. Over the years it has become apparent that although Semantic Versioning allows us to express breaking changes, it does not do a good job in supporting the actual transition from the old to the new. The Semantic Versioning of today favors the parties that are slow to adopt the change, making life hard for everyone else.
The Actor model is an architectural pattern designed to support high-scale concurrency without the need for locking constructs and with simple memory safety rules. This talk discusses how to add support for the Actor concurrency model to the OSGi environment. We want to retain the composition of OSGi services as the basic model for creating applications while at the same time allowing application developers to schedule concurrent execution with an actor runtime, rather than to use threads and locks.
IoT is one of the major markets in which the OSGi technology is being used. The range of use cases is endless, e.g. for smart home & energy management, condition monitoring and predictive maintenance for industrial machinery, reduce loss of harvest with connected agriculture solutions, improve traffic flow management as well as fleet management in smart cities.
In this panel we want to discuss the following topics that various OSGi members have been working on:
Graphql is a great alternative to REST and takes a lot of headache out of the Design of a good API. Created by Facebook and made Opensources a few years back, it has an increasing populairty. See how to use the Gecko GraphQL Whiteboard easiely expose your Services via GraphQL or write a specific custom API .
Testing OSGi applications is a little different from other platforms. This talk aims to get people started with testing on OSGi and provide an overview of the options as well as practical examples.
Unit testing
Testing starts at the unit test level. Every project should have a good coverage by really fast tests (<10s for all tests). The talk will show practical cases of unit testing declarative services based code and how to shield your business code from OSGi API. We will also look into some typical pitfalls.
Integration testing
In the meantime, agents and agent technologies are widely accepted as a conceptual approach for controlling energy systems in a Smart Grid context, and many research projects and pilots have already shown their applicability. From a global scope however, building proprietary software artifacts should not be the goal in critical system environments like the energy supply.