Alfresco SDK 4 : choisir entre module JAR et AMP sans compliquer le déploiement

Avec Alfresco SDK 4, le choix entre JAR et AMP doit dépendre du type d’extension, du mode de déploiement et de la stratégie de maintenance. La bonne décision est celle qui rend les personnalisations explicites, reproductibles et faciles à mettre à niveau.

Avec Alfresco SDK 4, le point de départ a change par rapport aux anciens projets. Le SDK pousse des projets conteneurises, bases sur Maven et Docker, et le JAR est devenu le format par défaut pour les extensions in-process les plus courantes. Cela ne veut pas dire que l’AMP a disparu. Cela veut dire qu’il n’est plus le reflexe systématique. Beaucoup d’équipes gardent pourtant le vieux schéma mental « Alfresco = AMP », puis se retrouvent avec une chaine de build inutilement lourde.

Si vous déployez déjà votre socle en suivant une logique industrialisee proche de notre guide Installer Alfresco Community avec Docker Compose, ou si vous etes en train de structurer vos extensions de repository autour d’un modèle de contenu Alfresco proprement déployée, le choix JAR versus AMP merite d’être tranche clairement. Il impacte la lisibilité du projet, la reproductibilite des builds et la maniere dont vous maintiendrez vos évolutions plus tard.

1. Ce qu’Alfresco SDK 4 change par rapport aux anciens projets

Le SDK 4 ne fonctionne pas comme les vieux projets Alfresco centres sur un WAR modifie à la main. Il généré des archetypes plus proches d’une usine logicielle moderne : modules Maven, images Docker, dépendances declarees, orchestration locale et intégration tests. Dans ce cadre, le JAR est pratique parce qu’il s’intégré naturellement au cycle Maven standard. Vous packagez, vous injectez le module dans l’image cible, puis vous redemarrez l’environnement de test.

Concretement, cela reduit une partie de la complexité historique. Une extension repository simple, un comportement Java, un web script, un modèle de contenu ou quelques resources Spring peuvent souvent vivre très proprement dans un module JAR. Vous gardez un projet lisible, vous evitez de raisonner comme si chaque personnalisation devait venir patcher un WAR, et vous faites converger votre socle Alfresco avec des pratiques DevOps plus classiques.

L’AMP reste toutefois pris en charge par le SDK 4. Il n’est pas obsolete; il devient optionnel. C’est une nuance importante. Le vrai sujet n’est donc pas de savoir quel format est « meilleur » dans l’absolu, mais lequel reduit la dette dans votre contexte.

2. Quand le module JAR est le meilleur choix

Dans la majorite des projets Alfresco Community recents, le JAR est le meilleur point de départ. C’est particulierement vrai si vous créez une extension repository autonome, facile a versionner et a redelivrer dans une image Docker. Le JAR fonctionne bien quand vous voulez garder une separation nette entre le code métier, la configuration de l’image et les tests.

Le format JAR est adapte dans plusieurs cas fréquents :

• ajout de comportements, policies ou services Spring côté repository ;
• déploiement d’un modèle de contenu versioné ;
• mise en place de web scripts ou d’actions techniques spécifiques ;
• personnalisation simple de Share dans un module dédié ;
• pipeline CI/CD ou l’on veut limiter les transformations d’artefacts et garder des builds deterministes.

Le benefice principal n’est pas seulement la simplicite du packaging. C’est aussi la predictibilite. Quand une équipe relance un environnement, elle sait plus facilement ce qui entre dans l’image. Cette lisibilité devient critique des que vous commencez a enchainer les sujets techniques sensibles, par exemple une montee de version Alfresco Community ou une stabilisation de la stack de transformation et d’indexation.

Autre avantage: le JAR colle bien à l’idee d’extension modulaire. Vous pouvez isoler le repository, Share, des tests d’intégration et la configuration Docker dans des modules clairs. Pour une PME ou une ETI qui veut garder la main sur ses couts de maintenance, cette sobriete compte davantage qu’un packaging heritage que personne ne veut vraiment revisiter.

3. Quand l’AMP reste pertinent

Dire que le JAR est le choix par défaut ne signifie pas que l’AMP n’a plus d’utilite. L’AMP reste pertinent quand vous devez embarquer une personnalisation qui s’aligne mal avec un simple module injecte, ou quand vous manipulez des cas de déploiement qui supposent encore une logique d’application explicite sur les composants Alfresco cibles.

Dans la pratique, l’AMP refait surface dans trois situations. La première concerne des personnalisations historiques que vous ne pouvez pas migrer proprement a court terme. La seconde concerne certains paquets tiers livres eux-mêmes en AMP. La troisieme concerne des équipes qui ont besoin de contrôler très precisement le contenu assemble dans l’artefact final ou l’ordre d’application des composants.

Le risque, ici, est d’utiliser l’AMP par inertie. Or un AMP ajoute une couche de mecanique supplementaire. Il faut l’assembler, l’appliquer, vérifier le résultat dans l’image finale et s’assurer que personne dans l’équipe ne suppose encore un comportement implicite des anciens scripts. Si cette couche n’apporte pas de valeur technique concrete, elle devient du bruit.

4. Les questions a poser avant de choisir

Le bon arbitrage vient rarement d’une preference personnelle. Il vient de quelques questions simples mais structurantes :

1. La personnalisation touche-t-elle surtout le repository, Share, ou les deux ?
2. Le projet doit-il intégrer des artefacts tiers déjà fournis en AMP ?
3. Votre équipe veut-elle un pipeline Docker lisible, reconstruit souvent et facilement rejouable ?
4. Disposez-vous d’un heritage applicatif que vous ne pouvez pas refondre tout de suite ?
5. Les tests d’intégration doivent-ils valider un module finement versioné ou un assemblage plus complexe ?

Ces questions evitent un mauvais debat. Le sujet n’est pas « quel format est le plus Alfresco ». Le sujet est « quel format reduit le cout de maintenance, d’évolution et de diagnostic ». Sur des environnements qui melangent déjà authentification, indexation, proxy, sauvegarde et intégrations documentaires, chaque couche inutile augmente le temps de retour à la normale quand quelque chose casse.

5. Une méthode pragmatique pour trancher

La méthode la plus sure consiste à partir du JAR, puis a documenter explicitement ce qui forcerait un AMP. Autrement dit, vous inversez le reflexe historique. Au lieu de dire « on part en AMP sauf preuve du contraire », vous dites « on reste en JAR tant qu’aucune contrainte technique serieuse n’impose autre chose ».

Cette approche apporte trois gains. D’abord, elle simplifie le démarrage. Ensuite, elle rend le projet plus facile a relire par une équipe qui reprend l’exploitation. Enfin, elle clarifie les exceptions. Si vous basculez vers un AMP, vous devez pouvoir nommer la raison: dépendance tierce, packaging imposé, contrainte d’assemblage ou compatibilité temporaire avec un patrimoine existant.

Pour un projet neuf, un bon schéma est souvent le suivant : repository en module JAR, Share en module JAR si nécessaire, conteneurs Docker versionés, tests d’intégration des le départ, et usage de l’AMP uniquement si un composant particulier l’exige encore. Cette discipline ressemble à ce que l’on recherche déjà sur d’autres briques Alfresco: des objets petits, explicites, versionés et rejouables.

6. Les erreurs qui coutent cher

La première erreur consiste a melanger sans gouvernance des modules JAR, des AMPs internes, des AMPs tiers et des modifications de configuration dispersees dans plusieurs Dockerfiles. L’environnement fonctionne parfois au debut, puis devient difficile a diagnostiquer. Personne ne sait plus si un comportement vient du code du projet, d’un paquet applique à l’image, ou d’un artefact herite d’un ancien lot.

La deuxieme erreur est de ne pas lier le choix de packaging aux tests. Si vous annoncez une stratégie modulaire propre mais que vous ne validez ni le build, ni le démarrage des conteneurs, ni les scenarios repository, vous gardez l’illusion d’une architecture saine sans sa preuve. C’est exactement le type de dette qui se revele au pire moment, souvent pendant une mise à jour ou une migration.

La troisieme erreur est plus subtile: croire que le format de packaging est purement technique et n’a pas d’effet sur l’exploitation. En réalité, il conditionne la maniere dont vous embarquez vos dépendances, dont vous expliquez votre socle à un prestataire, et dont vous reconstruisez la plateforme après incident. Une équipe support preferera presque toujours une chaine explicite à un assemblage charge d’implicites.

7. Ce qu’il faut retenir pour Alfresco Community

Sur Alfresco Community, le meilleur choix est généralement le plus simple a reproduire. Avec SDK 4, cela veut dire que le module JAR doit être votre option par défaut pour les extensions in-process courantes. L’AMP reste un outil utile, mais seulement lorsqu’une contrainte technique reelle le justifie. Ce renversement de perspective évite de transporter dans un projet 2026 des habitudes de packaging qui repondaient a d’autres contextes.

Avant de figer votre décision, prenez le temps d’aligner développement, exploitation et intégration continue. Si tout le monde comprend pourquoi le module est en JAR, quand un AMP serait accepte, et comment le résultat est teste dans Docker, vous eliminez une grande partie des frictions futures. C’est souvent ce niveau de clarté qui fait la différence entre une personnalisation Alfresco tenable sur la duree et une personnalisation qui devient opaque des la deuxieme livraison.

Votre chaîne de déploiement Alfresco reste-t-elle reproductible ? Faire revoir votre architecture d’extensions.