Thanks. I'll try to allocate some time to look at the latest improvements. And Cellar is on my experiments list anyway. I've lost my patience with Maven a long time ago, so to preserve my mental health, Maven is no option for my project.
Jeremias Maerki On 07.05.2012 17:51:20 Christian Schneider wrote: > Thanks for the insight into your system. It is always intersting how > other working solutions look like. It is a good inspiration to think in > some different directions. > > I think most of the requirements you have should work with maven, karaf > features and cellar for clusters. > > For me maven has the main benefit that there is a repository where all > development results end up. This is the ideal > base to deploy from. Of course you have basically the same but you had > to put a lot of effort into it till it worked. > > If you want to revisit how karaf works right now you can try the > examples from my tutorials. They show how to build with maven > and how to deploy using features. From my own experience this works > really well. For development you can use the dev:watch * > command in maven to watch for changes in your local repo. These get then > automatically redeployed. > > Btw. I recently removed the OSGi API from the karaf jar. So it might fit > your needs better already. It would be great if you could review the > current version in trunk. > If you have some proposals how to make it fit your needs without too > many changes I would really be interested to hear them. > > Christian > > Am 07.05.2012 16:27, schrieb Jeremias Maerki: > > (comments inline below...) > > > > Jeremias Maerki > > > > > > On 07.05.2012 11:38:43 Christian Schneider wrote: > >> I really like your setup it looks quite lean. It is very different from > >> how karaf works though. > >> So I am not sure how easy it would be to karaf open enough to also > >> support that style. Having boot time plugins could be interesting. > >> We already have the karaf activator that could be used for this. Perhaps > >> that could be a basis for achieving such an open setup. > >> > >> I have some questions about your setup: > >> > >> - We use maven as a repository of binary artifacts (bundles, simple > >> jars). What do you use for this purpose? > > Basically bundles in a shallow directory structure. > > > > I used to experiment with Apache ACE. Quite nice for production > > environments but during development it wasn't easy enough to achieve > > quick turn-arounds when re-deploying bundles in my development instance > > (or instances when I work on cluster functionality). So I ended up > > implementing a rather simple system: a servlet that observes a local > > directory. Each subdirectory represents a "profile" with n bundles. > > Special zero-length "import-profile.*" files let me include other > > profiles. Via distributed events (event admin over Hazelcast) I can make > > all instances sync with that repository. So, whenever I build a bundle > > it gets copied to one of the profile directories and is distributed to > > every node in the cluster within a couple of seconds. So, more or less > > ACE-very-light without manual steps. Basically, the client part of this > > is my management agent that I deploy via initial provisioning. > > > > I can also leverage FileInstall's ArtifactListeners to deploy configs, > > for example. > > > > One reason for this rather simplistic approach was that I want to have > > close control over the set of bundles that I want to deploy on the > > system. Essentially, I try to avoid the topic of transitive dependencies > > like this which is one thing I dislike about Maven (there's good and bad > > in everything). Since I'm building a document production system that > > might one day become open source with an Apache-compatible license > > policy, I want full control over what goes into the system. > > > > I guess in the long-term I might also want to go towards OBR. It should > > be easy to enhance the servlet so it produces OBR metadata from the > > bundles in its repository. > > > >> - While I see that your setup should work nicely it sure was a lot of > >> effort to create. Why did you choose to do so instead of simply using > >> plain karaf? > > Yes, it was quite a bit. But I had invested quite a lot of time already > > to try to make Ace do what I was looking for, but my requirements just > > didn't fit. I think Ace is great from the integration step on up to > > production, but I wanted something that gives me full control and that > > would work efficiently from my development environment up to production. > > Well, that's the deployment part... > > > > ...and for the container part: I guess it was several little things that > > let me do that: > > - I wasn't happy with the Maven directory outline in "system" and with > > startup.properties. > > - Another thing I didn't like was the embedding of the OSGi API in > > karaf.jar. That disallows running on the latest Felix. > > - I don't need the failover setup. I rather solve that with a cluster or > > hot stand-by. > > - The distinction between karaf.base and karaf.home is not clear enough > > to me. > > - I wanted to split karaf.data into a data (/var/local) and a log > > (/var/log) location. That would have been relatively easy to propose to > > Karaf, I know. After all, I was the one to suggest the karaf.data > > property. But that point was mostly an after-thought after already > > having started with my container. > > That's what I remember just now. I'm pretty sure I've had another point. > > > > > >> - What are the main features of karaf that make you use it compared to > >> plain felix? The maven support can not be it :-) > > - standardized properties for file locations (home, data, etc.) > > - the approach with properties files and property substitution > > - the shell and many commands (although I still write my own commands > > with plain RFC 132) > > - SSH console > > - Blueprint deployer > > > > I guess features are nice for experiments and demos, but I remember > > having troubles in the past so I didn't use them. I've never revisited > > that decision through new tests. I've not always been able to follow > > every development in Karaf. I noticed Cellar quite (too) late, for > > example. I had already implemented similar things. > > > > Generally, I still run into strange effects every now and then. Some > > third-party that was not really written for OSGi not behaving ideally, > > producing class loader issues or whatever. Keeping tight control over > > deployment allows me to counteract this to a degree. I sometimes wonder > > if I'm the only one running into so many little problems with various > > bundles. I love OSGi but sometimes I find it difficult to create a > > complex system where all components play nice from startup to shutdown. > > I often find myself up- or downgrading a particular bundle (and its > > dependencies) to work around a problem. > > > >> Genrally I am not a big fan of completely open systems as they fragment > >> the user deployments. If you mainly make your platform open then every > >> user will use it differently. > > I understand that completely. It also makes it more complex for newbies. > > I do think it's good that Karaf recommends a widely accepted best > > practice with the default installation. The "newbie kickstart" (unpack, > > drop a bundle in "deploy" and go) is one of the great things about Karaf. > > It's much easier to get OSGi newbies started on Karaf than with plain > > framework. But maybe it can get a bit more open for the advanced user. > > > >> That is not so good in relation to forming a community. So I am more a > >> fan of choosing a good path and using it (a bit like gnome vs kde or mac > >> vs linux). Of course in some areas modularity is really good but you > >> have to be careful. > > Agreed. But one size doesn't fit all. I like Ace but it's not for me. I > > "spent/wasted" a lot of time building basic components of my own. I'm > > pathologic in that area. I even wrote my Bnd alternative for Ant. How > > crazy is that? ;-) But it turned out that it was really easier (and > > faster) sometimes to build something that was tailored to my > > expectations that to beat something else into submission. Surely not in > > every case. > > > >> Christian > >> > >> Am 07.05.2012 10:17, schrieb Jeremias Maerki: > >>> (hooking into a random point in this thread, mostly agreeing with > >>> Guillaume and David) > >>> > >>> I'd like to offer my view on the topic. I've recently started moving > >>> away from the Karaf bootstrapper (still using many Karaf bundles, > >>> though). I ended up writing my own bootstrapper because I thought the > >>> current one does too much and imposes certain decisions. > >>> > >>> Here's where I am now: > >>> - "lib" directory for the bootstrapper (18KB) + framework(s) and service > >>> adapters (Commons Deamon, Wrapper etc., in the future to be implemented > >>> as plug-ins using META-INF/services like with the framework). > >>> - "lib/endorsed" directory: not nice but unfortunately I can't seem to > >>> do without, yet. > >>> - "bundles" directory for startup bundles. Can optionally have > >>> subdirectories with the start-level as name, ex. "bundles/10" for > >>> start-level 10. (No startup.properties) (Even this could be a "bootstrap" > >>> plug-in so others can implement their own choice of initial bundle > >>> provisioning.) > >>> - "etc" directory: minimally only contains a system.properties, > >>> framework.properties and jre.properties. > >>> > >>> In the production deployment, the installation really just contains a > >>> minimal set of 3 bundles (compendium, my initial provisioning > >>> implementation bundle and config admin). Initial provisioning fetches > >>> the management agent from a central place and invokes that to actually > >>> deploy the application. > >>> > >>> That allows me to put minimal configuration on each server and reduce > >>> the frequency in which the bootstrapper has to be upgraded. All the rest > >>> is fetched from a central deployment server. > >>> > >>> In my development environment, fileinstall and many other bundles are > >>> put in the "bundles" directory so I get a "Karaf-like" setup, skipping > >>> the actual deployment server (actually the local instance serves as that). > >>> > >>> I don't work with Maven, so I don't personally like that dependency, > >>> even it's just the directory layout in the "system" directory. The > >>> startup.properties doesn't even need to be kept in sync with that > >>> directory. > >>> > >>> Since I'm seeing multiple desires in this thread, why not make the > >>> container/bootstrapper much more modular and give the power to the users > >>> to choose their favorite setup? Karaf already offers a ton of very > >>> useful bundles that can but don't need to be used. You could extend that > >>> approach to the bootstrapper. > >>> > >>> Just my 0.05 CHF. > >>> > >>> HTH > >>> Jeremias Maerki > >>> > >> > >> -- > >> Christian Schneider > >> http://www.liquid-reality.de > >> > >> Open Source Architect > >> Talend Application Integration Division http://www.talend.com > > > -- > > Christian Schneider > http://www.liquid-reality.de > > Open Source Architect > Talend Application Integration Division http://www.talend.com
