You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@karaf.apache.org by David Orme <dj...@coconut-palm-software.com> on 2016/03/23 20:48:49 UTC
Introduction
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
Re: Introduction
Posted by Morgan Hautman <mo...@gmail.com>.
Hello David,
Welcome to the Karaf community!
Regards,
Morgan
2016-03-24 3:44 GMT+01:00 David Orme <dj...@coconut-palm-software.com>:
> Hi JB et al:
>
> Inline.
>
> On Wed, Mar 23, 2016 at 3:09 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
> wrote:
>
> > to be clear: what's the purpose of your e-mail ?
> >
>
> Thanks for asking.
>
> As a shop, we're pretty new to Clojure, so initially we took the path of
> least resistance and deployed applications as uberjars.
>
> Now we're ready to grow up. :-)
>
> And basically I think that a dynamic language like Clojure needs a dynamic
> modular runtime in order to deliver maximum benefit.
>
> So while I was writing the prior email there were two categories of things
> in the back of my mind:
>
> 1) Things I really need to do to make our existing portfolio of
> applications more maintainable, modular, serviceable, etc.
>
> 2) Features that would make the difference between getting the job done and
> really fulfilling the potential of putting dynamic (or dynamically
> compiled) languages inside a dynamic runtime--both at development and at
> runtime.
>
> But experience tells me that the most effective implementation of #2 will
> require a community, in every sense of that word. So I wanted to see if
> this particular community finds the vision I attempted to articulate
> compelling and in any case to simply introduce myself since it seems
> there's a good chance I might be hanging out here awhile either way. :-)
>
> The detailed technical responses are appreciated. Unfortunately, my
> response will need to wait until tomorrow. Look forward to writing more...
>
Re: Introduction
Posted by David Orme <dj...@coconut-palm-software.com>.
Hi JB et al:
Inline.
On Wed, Mar 23, 2016 at 3:09 PM, Jean-Baptiste Onofré <jb...@nanthrax.net>
wrote:
> to be clear: what's the purpose of your e-mail ?
>
Thanks for asking.
As a shop, we're pretty new to Clojure, so initially we took the path of
least resistance and deployed applications as uberjars.
Now we're ready to grow up. :-)
And basically I think that a dynamic language like Clojure needs a dynamic
modular runtime in order to deliver maximum benefit.
So while I was writing the prior email there were two categories of things
in the back of my mind:
1) Things I really need to do to make our existing portfolio of
applications more maintainable, modular, serviceable, etc.
2) Features that would make the difference between getting the job done and
really fulfilling the potential of putting dynamic (or dynamically
compiled) languages inside a dynamic runtime--both at development and at
runtime.
But experience tells me that the most effective implementation of #2 will
require a community, in every sense of that word. So I wanted to see if
this particular community finds the vision I attempted to articulate
compelling and in any case to simply introduce myself since it seems
there's a good chance I might be hanging out here awhile either way. :-)
The detailed technical responses are appreciated. Unfortunately, my
response will need to wait until tomorrow. Look forward to writing more...
Re: Introduction
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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 !
Regards
JB
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Introduction
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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é
jbonofre@apache.org
http://blog.nanthrax.net
Talend - http://www.talend.com
Re: Introduction
Posted by David Orme <dj...@coconut-palm-software.com>.
Thanks!
Regards,
Dave Orme
On Thu, Mar 24, 2016 at 1:52 AM, Serge Huber <sh...@jahia.com> wrote:
>
> > On 23 mars 2016, at 21:29, Achim Nierbeck <bc...@googlemail.com>
> wrote:
> >
> >> *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.
> >
>
> Actually I’ve used another trick to do very dynamic file updating. If
> these are web resources served by an HttpService, I’ve created a custom
> HttpContext that will look for a bundle header that points to the source
> code. If it exists I do file lookups in the source directly first, and then
> in the bundle. This way even without deploying a bundle you can load file
> updates !
>
> Of course this only works for resources, not for Java code.
>
> cheers,
> Serge…
Re: Introduction
Posted by Serge Huber <sh...@jahia.com>.
> On 23 mars 2016, at 21:29, Achim Nierbeck <bc...@googlemail.com> wrote:
>
>> *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.
>
Actually I’ve used another trick to do very dynamic file updating. If these are web resources served by an HttpService, I’ve created a custom HttpContext that will look for a bundle header that points to the source code. If it exists I do file lookups in the source directly first, and then in the bundle. This way even without deploying a bundle you can load file updates !
Of course this only works for resources, not for Java code.
cheers,
Serge…
Re: Introduction
Posted by Achim Nierbeck <bc...@googlemail.com>.
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