More information is coming soon.
More information is coming soon.
In this session, we will look back at the growth of the Eclipse IoT community, from just a couple open source projects in 2011, to a vibrant ecosystem of over 45 companies working on the open source technology used in some of the world’s leading IoT systems today.
We will give an overview of the Eclipse IoT technology portfolio and see how it is being used today to solve some real business cases such as asset tracking management or industrial production performance management.
Some of the key difficulties of managing large development teams are ensuring consistency across developer environments, helping new developers get their tooling and dependencies set up, and enforcing consistency among dev, test, and production environments. Eclipse Che solves this problem by provisioning and managing developer environments in the cloud on top of Kubernetes distributions like OpenShift.
There is currently a large hype surrounding the language server protocol (LSP) which provides a very flexible and well-proven architecture for implementing textual language support. Wouldn’t it be cool to use a similar protocol and architecture for graphical modeling languages, too? Following in the footsteps of LSP, is it possible to allow a “generic diagram editor” talk to a graphical language server, retrieving information such as how nodes are rendered, how they can be connected, or which elements can be created from a palette?
The move of enterprise and cloud-native specifications and technologies to the Eclipse Foundation under the Jakarta brand brings along with it the need to define a process for creating and evolving code-first specifications in open source. While specifications manifest as a collection of artifacts (a specification is a collection of APIs, descriptions of semantic behavior, data formats, and/or protocols intended to enable the development of independent compatible implementations), it's not quite as simple as dropping them into our existing Eclipse Development Process (EDP).
“Cloud Native”. It’s a great term, one that promises significant benefits for Java developers and Java applications. However there are traps for the unwary traveller undertaking this journey. It’s best to be prepared and forewarned. In this talk hear more about what Cloud Native Java looks like, and how it can differ from what you might be expecting. From application to JVM to hosting environment, there are challenges to face and obstacles to overcome before you’ve reached your goal.
Cloud native is the most hotly debated disruptive technology trend in software. In fact, this new trend has initiated a fundamental architectural design paradigm shift: modern web-scale applications are now constructed cloud native, based on latest microservice architecture principles.
The European Space Operations Centre (ESOC) is the main operations centre for the European Space Agency (ESA), operating a number of earth observation and scientific missions. Monitoring and control functions needed by spacecraft operators are provided by software systems which are reused across missions, but tailored and extended for mission specific needs.
The Eclipse foundation is hosting the OpenADx initiative, encouraging companies to collaborate on integrating different technologies and tools to accelerate the development of Autonomous Driving. This OpenADx initiative is initially being focussed around different testbeds.
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.
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.
Back to the top