On Tue, 2015-08-04 at 15:45 +0000, Justin Edelson 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.
Precisely :-) Robert > > 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 > > > > >
