Robert, Not to turn this email list into a theoretical discussion, but I'll say one thing, and then we can carry on the conversation privately or in different forum...
I think *the* primary reason OSGi has a place in the world, is because it can make completely incompatible set of things be able to run together. For example, if I have component A that requires version B of of some specific class but perhaps B is using an older component C than the version of C that A is using internally...then a single classpath cannot ever work. You must have an environment which gives each component it's own "world (i.e. separate classpath)" or environment to run in. What SpringBoot is all about, on the other hand, is saying let's design a single set of dependencies (Technology Stack) that are all *known* to work together (single classloader) on the same versions of all dependencies in the chain, and eliminate the version conflicting before it starts, thus eliminating *one of* the problems OSGi solves. So OSGi is great, but unless I run directly into one of the problems it solves, I don't need it. Spring already has "Spring Data MongoDB" and "Spring Data Solr" projects, and I think there should be a "Spring Data JCR" project also, that is basically JackrabbitOak packaged similarly to how I do it in meta64.com. That is, basically Oak dependencies, with a thin layer of spring beans exposing it, and a bit of AOP for session management, etc. My apologies if this is an inappropriate forum for such a discussion. Best regards, Clay Ferguson [email protected] On Tue, Aug 4, 2015 at 9:04 AM, Robert Munteanu <[email protected]> wrote: > On Mon, Aug 3, 2015 at 8:14 AM, Clay Ferguson <[email protected]> wrote: > > I looked at that readme page (oak-pojosr). I like the idea of simplifying > > use of osgi, or embedding it. It reminds me a bit of how SpringBoot > actually > > embeds an instance of Tomcat, so deployment is simple and easy for web > apps. > > > > Having a totally prepackaged way of doing stuff is what most developers > want > > these days. There are just too many moving parts in most large systems, > so > > people need "prepackaged" configurations that just work right out of the > > box, at least for some minimal set of the most common usage patterns. I'm > > not sure if there's any plans to integrate into SpringBoot, but IMO that > > would be a hugely important thing for the industry if Oak was part of > > SpringBoot stack. > > I'm not an Oak developer, so don't take this as any sort of official > statement, but the way I understand it the Jackrabbit project only > provides the Oak code / binaries ; packaging it in suitable formats > for development / deployment is left to packagers / other projects. > > One such example is Apache Sling ( https://sling.apache.org ), a > framework built on top of JCR, REST and OSGi. But if you're > well-versed in Spring and convinced that you should switch to OSGi it > won't help you much. In that case "someone" ( it's always someone else > :-) ) should provide that integration. > > Cheers, > > Robert > -- > Sent from my (old) compute >
