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
