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:09:03 GMT
Hi David,

to be clear: what's the purpose of your e-mail ?

Are you looking for some helps (contributions, users, tests, ...) ?
Is it more kind of announcement e-mail to introduce Closure ?

If you are looking for help to integrate your code in Karaf container 
(via karaf-boot or standalone), then, I would be more than happy to 
provide all help that I can.

Some of us are involved in big data ecosystem (like me), and it's 
definitely an area where we want to extend Karaf.

Your e-mail contain different interesting topics, really valuable for 
the Karaf community and Karaf projects.

If you don't mind, I would love to have a chat with you to completely 
understand what you need and how Karaf community can help you.

Thanks !

On 03/23/2016 08:48 PM, David Orme wrote:
> 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
> feedback).
> *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
> (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.
>     - 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?
> Regards,
> Dave Orme

Jean-Baptiste Onofré
Talend - http://www.talend.com

View raw message