karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Orme <...@coconut-palm-software.com>
Subject Introduction
Date Wed, 23 Mar 2016 19:48:49 GMT
Hello everyone,

I'm new here and wanted to introduce myself and gauge interest in some
ideas I've been kicking around for Karaf (and receive constructive

*Introduction: *I'm Dave Orme.  Some of you might recognize my name from
the Eclipse community; I was the co-architect of Eclipse's data binding
framework (with Boris Bokowski) and led the Visual Editor Project through
its early years at Eclipse.

I currently lead the "big data" team at Brad's Deals, an Internet startup
that pledges to bring people the best deals available right now on the
Internet.  We are looking at using Karaf as a standard deployment vehicle
for our JVM-based applications.

Our applications are currently mostly in Clojure, so I've been working on
creating proper Clojure integration for OSGi.

*Interest #1: *To my thinking, there shouldn't be just a single Clojure
runtime in an OSGi container shared by all bundles.  Similarly, bundles
shouldn't be required to uber-jar a Clojure runtime in order to obtain
classloader-isolated Clojure services.  Rather, my preference would be for
each bundle to be able to request a named Clojure environment from an OSGi
service that vends possibly multiple Clojure versions to any Bundle that
requests one (or has an injection site for one).  Each named environment
would be classloader-isolated from all other Clojure environments in the
container but also be served from a single Clojure Service Bundle.

I have a POC of this running in Equinox using the same mechanism Eclipse
uses to add its own plugin registry.  I'm currently trying to work out how
to integrate this code into a custom Karaf container build.

Ultimately, I would love to see this kind of service supported across all
OSGi runtimes supported by Karaf for all JVM alternative languages.

*Interest #2:* OSGi is dynamic.  Clojure (and similar languages) are even
more dynamic, permitting programmers to evolve a system as its running at
the level of individual classes and methods--in fact this is the usual
method of development for Clojure.

I would love to see (and help write) tooling making it easy to evolve Karaf
from within Karaf by (initially) exposing a REPL for any running bundle.
The REPL should accept commands using the syntax of any JVM-compatible
language registered with the OSGi container.

*Interest #3:* Support filesystem watching (or editor watching for
integrated editors) and hot-swap the bundle being developed into the
running environment either on-demand or automatically whenever there are no
syntax errors.  In conjunction with #2, this could make software
development more agile.

Lastly, here are a few underlying/guiding philosophical principles

   - Be editor agnostic.  Welcome anyone, regardless of their editor
   religion.  Any editor that can edit code in the deploy (or maybe src;
   haven't decided yet) folder is supported via an optional rebuild/reload on
   save semantic.
   - I'd love to write a Javascript / web-based editor based on any of the
   excellent Javascript code editors with first-class dynamic Karaf
   integration.  But even this editor should talk with the container using a
   documented protocol.  Basically, separate the IDE UI bits from the
   IDE/build bits so the IDE's core logic is really just a bunch of bundles
   (in a Karaf Feature) that one turns on during development and that operates
   over a RESTful protocol.  Further, this allows any existing editor or IDE
   to be extended to support the Karaf IDE.  Even further, this editor (or
   IDE) can live anywhere that is network-reachable from the container.
   - One result of the client-server networked IDE is that a developer
   could build AWS services in AWS on the machine that will eventually become
   the AMI that is promoted to PROD; yet because everything (even the IDE
   container used to create the code) was built from scratch using build
   tooling, the entire environment is also reproducible at any time.
   - Similarly, support but don't require Docker.  A Karaf instance may
   want to be co-located with a database server, for example.  Since the Karaf
   IDE services are accessible over the network anyway, the path of least
   resistance may be to create a Docker container mirroring exactly the one
   that will be deployed into PROD, connect one's preferred editor to the
   instance, and evolve the container into what it needs to be.
   - The build tool/build file is the single source of truth for all new
   bundles' metadata.  IDEs from the last decade use the IDE as the
   integration point in many cases, which can be a source of pain.  But build
   tools have matured a lot since 2000 and I believe that the build tool /
   build configuration should now be the integration point between the tooling
   and the runtime.  If this is successful, the fact that some build tools are
   still really slow (Maven--cough, cough) will encourage people either choose
   a build tool that is really fast and at the same time put pressure on the
   slow build tools to become faster.
   - The base Karaf container/IDE itself should be bootstrapped from Maven
   and include everything a person needs to start writing bundles in Karaf's
   supported languages by default.  Batteries included.  All you need to start
   is a JDK and Maven.  (Perhaps a choice of additional build tools will be
   included in the initial package too.)  As a result, it should be trivial to
   recreate an application's container and all the application
   bundles/features from a GIT clone of their respective repositories.
   - To the greatest extent possible, reuse the non-UI bits from Eclipse
   and/or NetBeans to the greatest extent their licensing allows.
   - Ideally, write web-UI tier code using web tooling / languages that can
   self-host inside the web browser (and sync with the host Karaf project on
   the fly).  This will itself need to be bootstrapped somehow since I don't
   believe any existing web-based code editors can be evolved from within
   themselves this way.

Thoughts?  None of this is set in stone (much less concrete) yet.  Anyone
else interested in something like this?


Dave Orme

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message