Justin, Correct. I was laying out the details of how JCR should relate to SpringBoot. I think I got it right. SpringBoot would include a JCR project, not the other way around. Jackrabbit would never depend on SpringBoot. However, if I were the architect of Oak, it would be using Spring Core (etc) internally nearly everywhere. :)
Best regards, Clay Ferguson [email protected] On Tue, Aug 4, 2015 at 10:45 AM, Justin Edelson <[email protected]> wrote: > Hi, > I don't think Robert (or anyone else) is saying that there *shouldn't* be > a Spring Boot-based distribution which uses Oak. But the Jackrabbit project > wouldn't necessarily be the right place for this. > > Regards, > Justin > > On Tue, Aug 4, 2015 at 10:08 AM Clay Ferguson <[email protected]> wrote: > >> 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 >>> >> >>
