Déplacement du fichier /WEB-INF/nuiton-js.properties dans le classpath
Bonjour, Nous aimerions déplacer le fichier /WEB-INF/nuiton-js.properties dans le classpath se qui entrainerait une incompatibilité par rapport à la version actuelle. Ou alors on le charge à deux endroits, mais l'idée me plait moins. Peut-on le mettre dans /WEB-INF/classes plutôt ? -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
On Thu, 11 Jul 2013 18:57:35 +0200 Eric Chatellier <chatellier@codelutin.com> wrote:
Bonjour,
Nous aimerions déplacer le fichier /WEB-INF/nuiton-js.properties dans le classpath se qui entrainerait une incompatibilité par rapport à la version actuelle.
Ou alors on le charge à deux endroits, mais l'idée me plait moins.
Peut-on le mettre dans /WEB-INF/classes plutôt ?
Perso avec le peu d'informations données dans ton courriel, je ne suis vraiment pas en mesure de te répondre. Pourrait-on faire un peu plus d'effort pour restituer le problème dans un ensemble générale. Sinon si la question est purement réthorique, je me demande bien à quoi elle sert... Les questions suivantes me viennent alors à l'esprit : - pourquoi on le charge 2 fois actuellement ? - pourquoi on veut le mettere dans le classpath ? qu'est ce que ça apporte comme amélioration - quelles sont les impacts à ça (tu dis que ça rends incompatible le fonctionnement, moi je sais pas pourquoi) Sans répondre à ce genre de question, je vois pas comment tu peux attendre des réponses d'autres personnes que celles avec qui tu en a discuté en privé (ce qui je suppose vu l'utilisation du *nous*), mais là encore si c'est juste informatif alors y'a pas de question à poser... Et une petite question subsidiaire : - mieux vaut-il rendre une API incompatible ou bien suivre une histoire de goût et de couleur ? (avec une réponse autre que je ne suis pas convaincu of course...) Bien entendu, personnelement je suis pour toute amélioration, si elle est justifiée et un tant soit peu expliquée :) Par contre je me rends compte que le fait de rendre incompatible les API devient trop souvent un leitmotiv dans le dev de nos librairies et ce n'est pas normal. -- Tony Chemit -------------------- tél: +33 (0) 2 40 50 29 28 email: chemit@codelutin.com http://www.codelutin.com
Le 12/07/2013 09:20, Tony Chemit a écrit :
- pourquoi on le charge 2 fois actuellement ? On le charge qu'une seule fois dans /WEB-INF/nuiton-js.properties - pourquoi on veut le mettere dans le classpath ? qu'est ce que ça apporte comme amélioration C'est un endroit plus standard pour les properties, dans WEB-INF c'est plutot du xml. Dans notre cas, on veux le considérer comme une ressource filtrable par maven, donc dans src/main/resources - quelles sont les impacts à ça (tu dis que ça rends incompatible le fonctionnement, moi je sais pas pourquoi) Cf réponse /1
-- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
On Fri, 12 Jul 2013 09:43:39 +0200 Eric Chatellier <chatellier@codelutin.com> wrote:
Le 12/07/2013 09:20, Tony Chemit a écrit :
- pourquoi on le charge 2 fois actuellement ? On le charge qu'une seule fois dans /WEB-INF/nuiton-js.properties
- pourquoi on veut le mettere dans le classpath ? qu'est ce que ça apporte comme amélioration C'est un endroit plus standard pour les properties, dans WEB-INF c'est plutot du xml. Dans notre cas, on veux le considérer comme une ressource filtrable par maven, donc dans src/main/resources
euh non assertion fausse! ce qui est filtrable n'est pas forcement dans src/main/resources ça me rapelle bien le allez on filtre tout dans ce répertoire juste pour avoir un fichier filtré bad pratice selon moi :(
- quelles sont les impacts à ça (tu dis que ça rends incompatible le fonctionnement, moi je sais pas pourquoi) Cf réponse /1
Si l'idée c'est juste de filtrer alors c'est prévu dans le plugin m-war-p: http://maven.apache.org/plugins/maven-war-plugin/examples/adding-filtering-w... Si ça réponds à tout besoin j'en suis très content et ça évite toute incompatibilité dans ta lib ;) Je pense qu'exposer le besoin avant de trouver un *hack* c'est mieux, parfois y'a des solutions simples qui peuvent t'aider. (enfin si dans le cas présent c'est vrai ^^). J'espère t'avoir aidé. tony.
Le 12/07/2013 09:50, Tony Chemit a écrit :
- pourquoi on veut le mettere dans le classpath ? qu'est ce que ça apporte comme amélioration C'est un endroit plus standard pour les properties, dans WEB-INF c'est plutot du xml. Dans notre cas, on veux le considérer comme une ressource filtrable par maven, donc dans src/main/resources euh non assertion fausse! ce qui est filtrable n'est pas forcement dans src/main/resources
Le filtrage n'est qu'une des 2 assertions. La plus importante pour moi étant que : la place des fichier ".properties" (chargées par le Java) est plus dans le classpath (WEB-INF/classes/ dans notre cas) qu'à un endroit batard (WEB-INF/). (cf [1] à ligne 77) Pour moi, c'est une *correction* nécessaire, mais qui entraîne malheureusement une incompatibilité,. À moins de tenter de charger (pendant un temps du moins) le fichier aux 2 emplacements (et avec affichage d'un warning si le fichier est chargé à partir de l'ancien emplacement), d'où la question d'Éric. Mais peut-être que vous jugerez que ce n'est pas gênant/nécessaire, auquel cas on ne change pas d'emplacement, on reste sur un truc bancal, et on a pas de soucis de compatibilité. Arnaud [1] http://www.nuiton.org/projects/nuiton-js/repository/entry/trunk/nuiton-js-wr...
Le 16/07/2013 10:08, Arnaud Thimel a écrit :
Le filtrage n'est qu'une des 2 assertions. La plus importante pour moi étant que : la place des fichier ".properties" (chargées par le Java) est plus dans le classpath (WEB-INF/classes/ dans notre cas) qu'à un endroit batard (WEB-INF/). (cf [1] à ligne 77)
Pour moi, c'est une *correction* nécessaire, mais qui entraîne malheureusement une incompatibilité,. À moins de tenter de charger (pendant un temps du moins) le fichier aux 2 emplacements (et avec affichage d'un warning si le fichier est chargé à partir de l'ancien emplacement), d'où la question d'Éric.
Sauf contre avis, je déplace le fichier dans le classpath. Et je lit une seconde fois le fichier dans /WEB-INF/ en affichant un warning. -- Éric Chatellier - Code Lutin Tel: 02.40.50.29.28 - http://www.codelutin.com
On Tue, 16 Jul 2013 10:08:24 +0200 Arnaud Thimel <thimel@codelutin.com> wrote:
La plus importante pour moi étant que : la place des fichier ".properties" (chargées par le Java) est plus dans le classpath (WEB-INF/classes/ dans notre cas) qu'à un endroit batard (WEB-INF/). (cf
Ce fichier est a cette place, car wro indique que ce fichier est lu depuis cette emplacement """ https://code.google.com/p/wro4j/wiki/ConfigurationOptions Intro The default way of setting them is by creating wro.properties file in WEB-INF folder (next to wro.xml). The way wro4j is configured is customizable, but this is out of the scope of this page. """ le fichier nuiton-js.properties est le pendant de wro.properties Voilà pour la raison de son emplacement actuelle dans /WEB-INF -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin@codelutin.com http://www.codelutin.com
participants (4)
-
Arnaud Thimel -
Benjamin POUSSIN -
Eric Chatellier -
Tony Chemit