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