Discussion :

[houdain]

Bonjour,

Je suis nouveau sur le forum. je travaille sur des projets développés sur eclipse dans une entreprise.
il y a utilisation d'un framework d'entreprise qui est déjà déployé sur les servers d'appli de prod.
Dans un projet en developpement, les dépendances à ce fwk sont donc en scope provided.
Mon but est de référencer les dépendances provided sur mon serveur Tomcat de façon automatique afin d'être au plus proche de l'environnement de production pendant la phase de développement.

Solution de contournement utilisé actuellement : j'ai créé une propriété pour variabiliser les scopes dans un profil dev et prod avec respenctivement les valeurs compile et provided.

Y a t il une solution pour référencer les dépendances provided dans mon tomcat de dev de façon auto ?

[gboissinot]

Tu peux extraire automatiquement les dépendances en scope provided de ton projet comme ceci par exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
mvn dependency:copy-dependencies -DincludeScope=provided -DoutputDirectory=addtionalTomcatLib

Toutes les librairies en scope provided sont alors copiées dans le répertoire 'addtionalTomcatLib'.

Il te suffira ensuite de les copier maullement ou automatiquement avec 'xcopy' par exemple.

[houdain]

hello,

Effectivement, c'est pas mal. J'ai paramétré la commande que tu m'as indiqué en tant que "run configuration" (voir PJ1).
Ensuite en administrant les jars copiés dans ce répertoire additionalLib en tant que classpath du serveur Tomcat (dans la partie serveur de run configuration), j'ai pu réaliser ce que je souhaitais.

C'est dommage qu'il n'y ait pas moyen de faire ça de manière plus automatique.
Cette problématique est elle si spécifique à mon entreprise ?

[gboissinot]

Je ne sais pas si ton besoin est spécifique à ton entreprise, néanmoins je dirais de mon point de vue que cela est peu commun.

Le serveur d’application fournit les librairies tierces (avec les implémentations des spécifications JEE) correspondant à ton serveur d’application.
Cela semble ne pas avoir de sens de rajouter toutes les librairies d’un scope provided dans le serveur d’application car tout simplement, la plupart des librairies sont déjà présentes au niveau de ton serveur

Il reste le cas des librairies additionnelles qui ne sont pas présentes par défaut dans ton serveur. Mais cela ne doit pas être automatique en fonction des dépendances d’un projet. Et surtout, pour éviter les potentiels conflits avec les librairies existantes, l’ajout de librairies au niveau du serveur d’application est difficilement automatisable. Et comme un serveur d'application a pour vocation de traiter plusieurs applications (projet), cela a priori peu de sens de rajouter des librairies spécifiques depuis un projet particulier.

[houdain]

Merci pour tes réponses, néanmoins je vais essayer de préciser mon contexte.

1) Avoir les librairies qui sont fournis par le serveur dans le pom en tant que provided me paraît normal. Es tu d'accord ?

2) Un développeur peut intervenir sur différents projets pour différents clients et donc être amener à développer sur des tomcats qui n'embarquent pas les mêmes librairies. Et dans ce cas il a besoin de pouvoir changer les librairies embarquées sur son tomcat le plus facilement possible.

Est ce un contexte que tu as déjà rencontré et comment y répondrais tu ?

[gboissinot]

Pour le point 1)
S'assurer que l'ensemble des libraires spécifiés en scope provided dans son pom.xml soient présentes au runtime, comme par exemple, au niveau du serveur d'application cible -> oui je suis d'accord.

Pour le point 2)
Si le dévelopeur intervient sur plusieurs projets pour des clients différents, c'est le TOMCAT du client qui est important. Il ne faut pas partir de l'application mais du serveur d'application. Avant de choisir la technologie et les versions, il faut savoir si cela sera possible de déployer l'application dans l'environement final du client. C'est la cible qui est important.
Et donc à chaque projet d'un client, un environement potentiellement différent et donc un environement de dévelopement (avec si besoin un Tomcat) différent.