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é
[email protected]
http://blog.nanthrax.net
Talend - http://www.talend.com
