Twenty-five years ago, two people, Marc Ewing and Bob Young, set up a business
to make available a Linux distribution created by Marc called Red Hat
Linux. That experiment of bundling a bunch of Free Software to make it
easy to be consumed has helped spawn, along with the Debian distribution,
a huge and diverse ecosystem of technologies that are now defining how
the world consumes technology, how societies are run, and is helping
drive the next generation of technical innovation.
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.
We will be ending the Eclipse IoT Day with a few lightning talks! Join the session and learn about:
- Eclipse Bridge.IoT - A decentralized Data Marketplace for the IoT — Stefan Schmid, Bosch Software Innovations.
- Making sensor programming dead simple with MRAA and UPM — Paul Fischer, Intel.
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.