Considerando JCR come una soluzione NoSQL?

Ho studiato un po 'di JCR eoni fa. È un'abile API Java per modellare un repository di documenti, con gerarchia, metadati, versioning, ecc., Ovvero un buon modello per il backend CMS. Esistono alcune implementazioni, in particolare il JCR open source, ma alcune "società CMS aziendali" avevano i propri prodotti basati su JCR. Jackrabbit ad esempio utilizza un database SQL sottostante.

Sfortunatamente, l'ecosistema JCR non sembra molto vivace. Quindi probabilmente il lavoro che ti salverebbe verrebbe probabilmente compensato dalla difficoltà di assumere persone che lo conoscono, dalla maturità delle biblioteche, ecc. Esistono alcune cose promettenti, come Sling, che è un bel framework web su JCR che potrebbe essere una buona base per costruire siti CMS-ey.

Darei un'occhiata a JCR; se le cose che implementa sono cose di cui hai bisogno, potrebbe valer la pena adottarle se trovi una decente implementazione opensource (Jackrabbit).

Sembra che JCR sia solo un'interfaccia / API generica che potrebbe essere implementata da una terza parte (simile a JMS). Quello che dovresti fare è cercare il supporto JCR di terze parti che appare, il tuo link su Wikipedia fornisce alcuni esempi.

Se si sta creando un'applicazione che un cliente installa sul posto e che deve essere integrata con più archivi di documenti, JCR potrebbe essere il percorso che fa per voi. Tuttavia, se gestisci lo stack dall'alto verso il basso, direi che scegli un negozio direttamente e lo utilizzi direttamente per il momento.