Setting up an OSGi project and running the application with bnd and Bndtools is quite easy as it provides the basics to get a developer started. Unfortunately, the default templates only get you settled with the basics. Companies have certain requirements on their code and often require builds to match the requirements of their company processes. Thus, something extra is required to help new developers get ready to roll and this tutorial will explain how this can be achieved. Attendees will understand how they can setup new projects and workspaces accordingly.
Think of Marie Curie. Would you expect to find a fascinating number of similarities between the Curies' treatment of their work in the early 1900s and today's tech industry?
OSGi was originally designed for Smart Homes and Residential Gateways almost 20 years ago.
This talk will present how the OSGi specifications have evolved over the years, and how you today, in 2018, design an OSGi based Smart Home System.
A real world use case of a Swedish Smart Home start-up company will be used to illustrate different design principles and how OSGi remains as relevant today as it was when it started.
- Small fit-for-purpose executables
- Put the micro in Microservices
- Minimal Docker images
- Does Java have what it needs?
As most organizations do not have the luxury of completely rebuilding their technology foundation or immediately adopting new practices and mindsets, they are embracing gradual yet fundamental shifts in culture, processes, and technology to support greater velocity and agility. With software increasingly key to how users engage with businesses and how businesses innovate to stay competitive, the speed of application development and delivery is the new digital business imperative.
Modeling and simulation is becoming a key development methodology for smart and safe systems containing integrated software, hardware, and communication components, interacting with physical (and social) environments. Simulation promises to provide early feedback on critical design decisions.
The OSGi framework, and the service specifications, is a powerful and simple way to build modular software. However writing modular software is hard and even a simple framework doesn't necessarily make things easy, especially when you are writing an application server consisting of over 100 discrete features. When that application server needs to dynamically respond to configuration changes, provisioning (or deprovisioning) features as required. Even worse when it has to support Java EE applications which are written with a totally different modularity (cough-cough) model.
Conventional wisdom has it that Java EE is a bad starting point for building cloud-native Java applications, but despite this most cloud-native frameworks are designed to use and extend Java EE. The issue has been not that Java EE can't be used, but deploying applications to new cloud platforms like Docker and Kubernetes so they can be efficiently updated and scaled requires new API's. Enter the Eclipse MicroProfile initiative which, combined with Jakarta EE, has been rapidly building out these gaps.
Eclipse Mars introduced the new Eclipse Automatic Error Reporting system (AERI), which lowered the hurdle to send error reports dramatically. Users will get into contact with this system when an error occurs in the IDE and a popup message requests to send this incident.
Every so often we need to introduce a new developer into our team who might not have experience with OSGi nor any other modular system. Have you ever thought how we can make adoption of new comers into your ecosystem easier?
Most of OSGi projects require some kind of tooling during both - build and development time. While we might live without second reliability of first one is a key of stable builds. As new hire you probably went over some introduction showing how to use properly tooling and surrounding infrastructure in order to become productive. Lets see together how much we can simplify.
While increasing amount of features usually result in poorer performance and more memory consumption, Eclipse Photon has proven the opposite: The Eclipse Platform got faster and less memory hungry than before. This has been achieved by intensive profiling of multiple use cases and refactorings derived from the analysis.
Web tools and cloud architectures are great but what does this actually change for developers?
Each contributor currently has to setup his local environment in order to actually contribute to a project. But how about configuring just a single environment for everyone in the cloud? What if your developers didn't even have to be using a specific local environment to work on a product? This is possible using a workspace server dispatching pre-configured containers to your teams, along with all the tools they need.
There is a new platform in town: Kubernetes. And it is establishing itself as the common denominator for public and private clouds with unprecedented momentum.
This talk is for you when you sensed that Kubernetes may be important and are wondering if using it is more straightforward than spelling its name.
Have you ever got upset and felt to cry out loudly (or you just did so) when you had an SQL statement failing somewhere deeply embedded in your code? Was it easy to find and fix it? Still today, many database libraries force us to embed SQL in the code, which is then very cumbersome to maintain. Fragments of query strings are scattered throughout the source code and we never really see the final SQL statements assembled and sent to the database. What is even worse, the SQL code is not processed at compilation time and – in the worst case – a syntax error can remain in production code.
Codegenerators are everywhere even when you don’t call them so. At the end something that is not text is translated to text. The technologies that are used are very diverse. There is no framework to rule them all, but there are modern technologies out there that will do things differently like we did it 20 years ago. From straightforward model to text to model to model to model to model to model to model to model …. to text - everything is there, but do you really know what is there today? Do you know what to use and why? Do you know when to use what?
OSGi Compendium R7 provides a major update to the OSGi LogService specification. A new logging API is added which supports logging levels and dynamic logging administration. A new Push Stream-based means of receiving log entries is also added. But it is quite often the case you need to use other code such as open source projects which are using slf4j for their logging API. This session will explore the new OSGi LogService changes and how you can integrate code using both slf4j logging and OSGi LogService logging.
Java 9 introduced the Java Platform Module System (JPMS) as a way to modularize the Java platform and it can be also be used by developers to modularize their own applications, although JPMS lack a number of important features for software running on the Java platform.
As people look to support the latest versions of the Java platform, changes introduced in Java 9 related to JPMS led to the needs for some features in the OSGi Core specification. OSGi framework implementations like Eclipse Equinox and Apache Felix and tools like Bnd were updated to support these new features.
As more Eclipse projects are migrated to the new cluster based build infrastructure, it's time for an update on the current status and to share best practices how projects can make the most of it. The following questions (and more) will be answered: Why does my build take so long and how can it be made faster? What are Jenkins pipelines and why/when should they be used? Can I finally run docker based builds?