D'après le changelog, il est prévu de :

Revoir le checkStyle d'esup-commons pour eclipse Indigo

Je me propose donc pour effectuer cette tâche. L'objectif est de produire un fichier checkStyle et de reformater l'intégralité du code d'ECV2 conformément à celui-ci. Je profite de ce moment car aucune PR n'est attente (donc pas de merge).

Lors de mes développements applicatifs (servlet et portlet), j'utilise Spring MVC, JSTL, JPA et CAS. ECV2 apporte déjà toutes ces dépendances avec des versions plus ou moins anciennes, mais aussi toutes une pléthore d'autres dépendances inutiles (pour mes projets). J'ai donc pris l'habitude de ne plus utiliser les modules ECV2 mais directement les technologies sur lesquelles il s’appuie. Quand je ne peux me passer d'un module, disons esup-commons2-auth, je suis donc obligé d'exclure manuellement une dizaine de dépendances et d'utiliser dependencyManagement afin de contrôler les versions des artifacts que je désire garder.

Cela n'est pas sain, je ne devrais pas avoir à me soucier de ces choses là.

Je propose donc quelque chose de simple. Beaucoup de développeurs se servent d'un archetype. Pourquoi ne pas inclure les dépendances réellement nécessaires directement dans le POM ? Je pense notamment à Spring et JSF pour les archétypes correspondant. Ainsi, les modules d'ECV2 ne sont plus là pour tirer les dépendances mais pour apporter du code.

Mais pourquoi revoir le mode de fonctionnement ? La réponse est très simple. Prenons le cas de Spring 3.0. L'artifact spring-webmvc-portlet possède une dépendances sur Portlet 2.0 ! La solution est de l'exclure et d'ajouter le bridge JSR-168 (développé pour Spring 2.5). Sauf que voila, parfois, ça ne se passe pas comme prévu et des ClassNotFoundException font leur apparition. La solution ? Utiliser Spring 2.5, sauf qu'ECV2 tire Spring 3.0 ! Une gymnastique est donc nécessaire afin de faire cohabiter tout le monde...

J'ouvre donc une discussion concernant les points suivants :

• Comment régler proprement ces soucis de dépendances ?
• Est-il envisageable de retravailler les dépendances d'ECV2 et des archétypes ?
• Est-il envisageable de revoir le fonctionnement de certains modules ?

Je suis en train d'essayer de configurer Shibboleth comme indiqué ici :
http://bit.ly/1gpSOZ0

J'ai donc remplacé :

<bean id="authenticatorService" lazy-init="true"
    class="eu.ueb.acem.services.auth.AuthenticatorServiceImpl">
    <property name="authenticationService" ref="${auth.bean}" />
</bean>

par :

<bean id="authenticatorService" lazy-init="true"
    class="eu.ueb.acem.services.auth.AuthenticatorServiceImpl">
    <property name="authenticationService" ref="authenticationService" />
</bean>

Puis j'ai ajouté la configuration du bean pour Shibboleth telle qu'indiquée dans la documentation :

<bean id="authenticationService" lazy-init="true" class="org.esupportail.commons.services.authentication.ShibbolethApacheModuleAuthenticationService">
    <property name="idHeader" value="" />
    <property name="attributeHeaders">
        <list>
            <value></value>
        </list>
    </property>
</bean>

Avec cette configuration, le serveur Tomcat plante dès le démarrage avec :

Cannot convert value of type [java.util.ArrayList] to required type [java.lang.String] for property 'attributeHeaders': no matching editors or conversion strategy found

Si l'on passe les attributs dans une chaîne séparés par des virgules, l'erreur disparaît:

<bean id="authenticationService" lazy-init="true" class="org.esupportail.commons.services.authentication.ShibbolethApacheModuleAuthenticationService">
    <property name="idHeader" value="uid" />
    <property name="attributeHeaders" value="o,mail" />
</bean>

Il faudrait corriger la documentation.