karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jean-Baptiste Onofré ...@nanthrax.net>
Subject Re: Introduction
Date Wed, 23 Mar 2016 20:42:14 GMT
Hi David,

some details inline:

> *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.

I would advice to base most of your design on OSGi services. It will 
work in any container, including Karaf. An advantage in Karaf is that 
the different layers (shell console, JMX MBeans, etc) can use these 
services.

>
> *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.

You can create a Karaf feature providing shell commands and MBeans to 
manipulate Clojure REPL. It's what I'm doing in Beam, Spark, HDFS and 
other projects.
For instance, in karaf-docker/karaf-boot, I'm creating a docker image 
for the current running container.
So we can imagine the same for Clojure REPL.

>
> *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.

I created a URL handler for HDFS 
(http://blog.nanthrax.net/2013/07/apache-hadoop-and-karaf-article-1-karaf-as-hdfs-client/).

We can imagine to provide new Pax URL handlers to deal with filesystem 
swapping (not sure it's required as the bundle:update can already do 
that, for instance the current location of the bundle is mvn:... and we 
can do bundle:update file:...).

>
>
> Lastly, here are a few underlying/guiding philosophical principles
> (manifesto?):
>
>     - 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.

It could be IDE (I'm not a big fan), and a full web application that you 
can deploy in Karaf (as we do with Decanter dashboards).

>     - 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.

A combination of karaf-boot/karaf-docker/karaf-profiles could do the trick.

>     - 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.

It's exactly what I gonna push soon on karaf-boot (karaf-boot 
bootstrapping will generate a runnable jar or runnable docker image).
I'm also preparing a blog about Rancher to show how to deal with Karaf 
dockers and Rancher.

>     - 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.
>

Ready to help sir ! ;)

Regards
JB


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

-- 
Jean-Baptiste Onofré
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com

Mime
View raw message