Bonjour,
Je me pose la question de savoir si l'on peut faire prudemment des patches d'une appli en fournissant uniquement les classes qui ont été modifiées.
Voici mon problème plus en détail.
J'ai développé un client lourd java que j'ai livré à un département chargé d'en faire des fichiers d'installation *.msi pour installation sur les postes des utilisateurs (vous allez, dire que c'est con de faire des *.msi alors qu'on peut déployer aisément avec Java web Start, mais voyez-vous, c'est pas moi qui décide ce genre de choses .....).
Bref, revenons à nos moutons :
Une fois que les *.msi sont réalisés et déployés sur les postes des testeurs et que certains bugs sont signalés, Le client pour qui je travaille m'impose de liver des "patches" consititués uniquement des *.class correspondant aux sources que j'ai modifiés lors de la correction des bugs.
Je suis contre ce principe parce que je pense qu'il peut arriver que des classes qui n'ont pas été compilées ensembles ne marchent pas bien.
D'ailleurs, il y a depuis 2 jours un nouveau bug est apparu après la livraison d'un de ces patches. Ce bug ne se produit pas sur mon poste parce que justement (selon moi) mes classes ont été compilées ensembles.
Le bug en question est que l'URL d'un fichier de config n'a pas pu être construite.
Le code dont je me sers pour pour charger ce fichier de conf a toujours marché. Ce code renvoie un objet de type java.net.URL. C'est le code suivant :
this.getClass().getClassLoader().getResource(configFileFullPath)
où configFileFullPath est un String représentant le chemin du fichier à partir de la racine des package, par exemple :
"com/mycompany/project/aspect/config.xml"
Savez-vous si j'ai raison ?
Est-ce que de façons générale (en dehors de RMI) des classes qui n'ont pas été compilées ensembles peuvent conduire -au moment de l'exécution- à un comportement erroné ? Pourriez-vous argumentez votre avis par des exemples ?
Avez-des références à ce propos que je peux consulter sur le net ?
Merci
Partager