search

EsupPortail / esup-helpdesk

6 stars 5 forks source link

userInfo.xml, feed.xml, export.xml, email.css, custom.css #6

Open ogermes opened 10 years ago

ogermes commented 10 years ago

Dans la version 3.29.10 de esup-helpdesk j'ai personnalisé les fichiers userInfo.xml, feed.xml, export.xml, email.css, custom.css

Dans la distribution 3.30.3 les fichiers userInfo.xml, feed.xml, export.xml sont inclus dans des jar. D'autre part le fichier email.css n'existe pas.

Est-il possible de revoir le packaging de la version 3.30.3 pour faciliter la personnalisation. Je suppose que dans la version 3.29.10, tous les fichiers du répertoire properties/domain sont ceux destinés à être personnalisés. Merci. Odile.

raymondBourges commented 10 years ago

Je vois le pb.

Une solution serait peut-être de mettre le chemin d'accès à chacun de ces "fichiers de configuration Spring" sous forme de properties dans le fichier de configuration. J'ai noté l'histoire dans notre outil de gestion. Je ne sais pas encore dire quand on va la traiter.

nhenry commented 10 years ago

Réalisé dans la version 3.30.5. Pour remplacer les fichiers de configuration Spring livrés avec l'application (userInfo.xml, feed.xml, export.xml), il faut renseigner le chemin d'accès de ses fichiers Spring personnalisés dans le fichier de configuration config.properties. Voir le "config.properties.example" livré. Les fichiers personnalisés viendront remplacés ceux par défaut. Custom.css : renseigner l'url d'un nouveau custom.css dans le fichier de configuration. Il viendra remplacer le custom.css par défaut. email.css : renseigner l'url ou le path d'un nouveau email.css dans le fichier de configuration. Il surchargera alors le email.css livré avec l'application.

vbonamy commented 9 years ago

Je pense que les modifications permettant de résoudre cette issue ( 2f9da661c0a2869d20bc5cb891e9624f65532508 ) ont malheureusement amené un peu trop de complexité. Tant au niveau de la configuration, qu'au niveau du code (classes du package org.springframework.context.support notamment ...).

Il faudrait je pense revenir simplement à un packaging plus classique - en passant simplement des 3 modules maven à 1 seul module maven - ça simplifierait les choses pour le développeur et le déployeur. Côté Esup, c'est finalement ce qu'on a fait pour quelques projets, dont EsupHelpdeskViewer ; après avoir constaté que ces sous-modules maven étaient la plupart du temps (dans nos cas d'usage) une fausse bonne idée ...

Avec un seul module maven, les fichiers de conf se retrouveront ainsi comme avant non pas dans un jar mais en répertoire WEB-INF/classes directement ...