karaf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Achim Nierbeck <bcanh...@googlemail.com>
Subject Re: Introduction
Date Wed, 23 Mar 2016 20:29:30 GMT
Hi David,

looks like you have a big project at mind and seem to do some sort of
sanity check here :)
so let me give you some feedback 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.
if it's OSGi and services it should run on any framework, may that be
equinox or felix.

> *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.
With the karaf shell I think it should be possible to have a closure 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.

Sounds like you want to build bundles on the fly, one point to start would
be to have the Pax-Swissbox bundle at hand, to create "Tiny-Bundles". If
it's more like a static monitoring of a filesystem, we already got that
with felix-fileinstaller.

> 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
>    to be extended to support the Karaf IDE.  Even further, this editor (or
>    IDE) can live anywhere that is network-reachable from the container.

If it's a "web-application" it can run on Karaf, as you can have
web-applications communicate with a service, the service which creates
tiny-bundles from repl code could be attached.

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

Sound a lot like the Karaf Profiles ... maybe look into how those might fit
your picture.

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

Afaik, people already created docker boxes from a "running" karaf instance.

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

This is exactly what karaf-boot should help with.

>    - 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?
> Regards,
> Dave Orme


Apache Member
Apache Karaf <http://karaf.apache.org/> Committer & PMC
OPS4J Pax Web <http://wiki.ops4j.org/display/paxweb/Pax+Web/> Committer &
Project Lead
blog <http://notizblog.nierbeck.de/>
Co-Author of Apache Karaf Cookbook <http://bit.ly/1ps9rkS>

Software Architect / Project Manager / Scrum Master

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