Je vous suggère de vous concentrer sur les solutions basées sur la spécification JSR-170 ou mieux sur la spécification JSR-283 qui est mise en œuvre par Apache Jackrabbit.
Cela dépend de ce que vous voulez en faire. Je serais intéressé par la prise en charge de la spécification des portlets, par les portails pris en charge par le CMS et par la profondeur de l'intégration en plus de la simple couche de visualisation. Les portails vous fournissent l'habillage pour le CMS, de sorte que vous n'avez pas à le créer vous-même.
Ce sont des solutions avec lesquelles j'ai travaillé ou joué.
Fronde Apache - Tout d'abord, je donnerais une chance à Apache Sling, parce que je considère que c'est un bon CMS Java programmable sous la forme d'un cadre web qui vous aide avec l'interface utilisateur, la gestion des utilisateurs et des choses sous la forme de REST, divers traitement des demandes comme json, et d'autres normes qui vous aident à construire CMS. Ainsi, il est plus facile d'employer simplement jackrabbit. Il fournit pratiquement la visualisation des éléments (nœuds/properties) dans Jackrabbit via le système de templating, vous pouvez utiliser jsp ou scripting (javascript, groovy etc.). Il y a aussi un backend sympa.
Hippo CMS - Une autre solution basée sur jackrabbit, des technologies et une architecture intelligentes et des caractéristiques générales. Ils ont fait un très bon pas en avant avec l'intégration du portail jetspeed 2. Je viens d'essayer le portail Hippo récemment et j'ai étudié Hippo en détail et je suis vraiment impressionné.
magnolia-cms - L'avantage de Magnolia est qu'il supporte à la fois JackRabbit et ModeShape, sinon je ne le connais pas beaucoup pour le juger. RetHat l'a choisi pour construire son JBoss.org dessus.
Nuxeo - Nuxeo a abandonné le support de JCR et a créé son propre moteur de contenu. Peut-être le syndrome du "pas inventé ici", mais je ne trouve pas cette décision judicieuse. Je n'aime pas tout ce qui n'accepte pas des normes et des spécifications bien éprouvées. Principalement parce que vous apprenez la spécification une fois et ensuite vous comprenez tout ce qui met en œuvre cette spécification. Je ne voudrais vraiment pas avoir à gérer des idiosyncrasies spécifiques à Nuxeo, passer de longues heures à apprendre ce qu'ils ont créé ou résoudre des bugs spécifiques au moteur Nuxeo cms.
Alfresco pour une solution orientée vers la gestion de documents / ECM - beaucoup de fonctionnalités, d'options d'intégration, des tonnes de technologies à apprendre pour qu'un développeur puisse l'utiliser entièrement, par exemple surf de printemps pour l'IU
Jackrabbit même si vous avez des développeurs compétents pour le construire selon vos besoins. Et des tonnes de temps disponible pour créer l'interface utilisateur.
ModeShape il est plus ou moins similaire à jackRabbit, qui est plus dépourvu de fonctionnalités que ModeShape... jackRabbit est un peu en retard sur l'implémentation de référence JCR (UserManager + ACL basé sur le principal ) ModeShape est loin derrière la mise en œuvre de référence. Les futures versions devraient avoir même une couche d'interface utilisateur, donc il semble que ce soit aussi un projet de perspective. Voir comparaison . C'est le deuxième jour que je développe un référentiel avec ModeShape et je dois dire que c'est l'un des meilleurs projets que je connaisse, en ce qui concerne la conception, la facilité d'utilisation, les idées, la maintenabilité et la documentation. En ce moment, je suis en train de refactoriser le traitement des documents (métadonnées/extraction de texte) dans sa version Séquenceurs ...aime beaucoup
- ils disent qu'il est possible ou qu'il sera possible de combiner ces deux-là, mais je n'ai pas trouvé d'informations à ce sujet
GATEIN solution de plate-forme : http://wiki.exoplatform.com/xwiki/bin/view/JCR/eXo+JCR+Mise en oeuvre - C'est intéressant, surtout depuis le partenariat exo+JBoss. Il vous faudrait autant de temps que pour liferay, je pense :-)
Il est également très important de vérifier la prise en charge d'AtomPub. Cette norme/protocole RFC 5023 est de plus en plus forte et elle joue un rôle important dans l'échange d'informations. Les CMS doivent être capables d'importer/exporter du contenu via AtomPub, ou au moins avoir une bonne documentation pour l'intégration avec un serveur AtomPub comme Apache Abdera. Par exemple, Google a tout misé sur AtomPub si l'on regarde la manière dont ses API sont réalisées. Ensuite, le support CMIS est également le bienvenu, car votre dépôt pourrait alors être facilement accessible par des tiers. Par exemple, vous pourriez le monter dans la bibliothèque de documents Liferay et en exploiter le contenu.
J'utilise Liferay depuis 2 ans maintenant et je l'adore. Bien que ce soit une mauvaise décision de l'utiliser pour une solution de gestion de contenu et de la construire par-dessus. Il dispose d'une bibliothèque de documents et d'une bonne gestion du contenu Web, d'un flux Web de documents, etc., mais il n'adhère à aucune spécification ou norme CMS, ce qui est nécessaire pour que les développeurs tiers puissent l'étendre ou le modifier. Il possède son propre système qui fonctionne très bien pour la gestion des documents de Liferay et l'intégration avec des référentiels tiers. Mais je ne recommande pas de l'utiliser pour construire quoi que ce soit par-dessus. C'est juste un portail qui contient ECM, WCM et gestion de documents Vous avez une solution prête à l'emploi qui fonctionne bien, mais vous avez du mal à l'enrichir de nouvelles fonctionnalités.
