Les options de mise à jour automatique du module complémentaire sont codifiées dans addin.defQu'est-ce qui a motivé cette demande ? Avec la sortie de JMP19, j'ai remarqué une fonction de mise à jour automatique des modules complémentaires : JMP recherche les mises à jour des fichiers dans un « dossier d'installation ». L'implémentation était un peu maladroite et a fini par perturber une partie de l'infrastructure que nous avions déjà mise en place.
Quelle amélioration souhaiteriez-vous voir ? Au lieu d'être gérées par les paramètres de Vues > Modules complémentaires, ces options devraient être intégrées au fichier addin.def, indispensable à tous les modules complémentaires. Cela simplifiera la gestion pour les utilisateurs disposant d'infrastructures existantes et facilitera l'intégration progressive des fonctionnalités intéressantes de JMP.
Pourquoi cette idée est-elle importante ? Je souhaite développer davantage cette fonctionnalité. C'est une excellente idée, mais son implémentation actuelle peut facilement engendrer des problèmes. Dans mon infrastructure actuelle, les mises à jour sont vérifiées par rapport à une liste principale afin de savoir quand de nouvelles versions sont publiées. La fonctionnalité de JMP pourrait simplifier ce processus, mais sa conception doit être améliorée. Quelques exemples :
1. L'extension est installée correctement, tout va bien… mais plus tard, l'utilisateur n'a plus accès à cet emplacement et a besoin de la mise à jour. Je lui transmets le fichier jmpaddin pour qu'il puisse continuer à l'utiliser. Il le glisse dans JMP… or, il est possible que le répertoire d'installation soit désormais le dossier Téléchargements et qu'il ne reçoive pas les notifications de mise à jour à cause de ce changement… Intégrer directement le répertoire d'installation correct dans le fichier de définition permettrait de résoudre le problème.
2. Modules complémentaires de test. Comme pour le point n° 1, si vos tests sont stockés dans un dossier, l’installation d’un fichier de test modifiera votre répertoire d’installation pour pointer vers le répertoire de test. Les tests ne seront donc pas notifiés lors de la publication d’une nouvelle version de production. De plus, selon la façon dont les fichiers sont nommés, les tests peuvent être notifiés ou non des nouvelles versions de test… car les versions de test sont souvent transmises et incluent le numéro de version dans leur nom de fichier. Par conséquent, une correspondance exacte des noms de fichiers est impossible pour les vérifications de mise à jour.
Dans ces deux exemples, certains aspects des solutions apportées par JMP pourraient s'avérer utiles, mais l'équipe de déploiement a besoin de davantage de contrôle sur la manière dont ses modules complémentaires doivent être marqués pour la mise à jour. Il existe probablement d'autres exemples, mais je pense que cela suffit pour lancer le processus d'intégration des éléments de mise à jour dans le fichier addin.def, avec une ou plusieurs variables.
Merci!
Automatisation et scriptageRe : Choix de mise à jour automatique du module complémentaire codifiés dans addin.defMerci @nathan-clark d'avoir souligné les problèmes.
Quelle est la vitesse de la nouvelle approche par rapport à « les mises à jour sont vérifiées par rapport à une liste principale » [comme dans Gestionnaire de compléments par @Justin_Chilton ] ?
Re : Choix de mise à jour automatique du module complémentaire codifiés dans addin.defJe n'ai pas encore effectué de tests de vitesse, @hogi . J'étais surtout agacé par le fait que cela posait des problèmes avec mes autres déploiements. Je pense que la vitesse serait globalement plus rapide, car JMP semble se contenter de vérifier les nouvelles modifications de nom de fichier, contrairement à ma comparaison avec les dates de publication réelles des builds. La vitesse sera également déterminée en fonction du dossier « source » référencé par JMP.
Re: Choix de mise à jour automatique du module complémentaire codifiés dans addin.def - Statut modifié en : Pris en compteMerci d'avoir pris le temps de partager cette demande ! C'est un excellent retour d'information.
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.def@nathan-clark Pourriez-vous me fournir la documentation relative à cette fonctionnalité et à son implémentation actuelle ? Je ne comprends pas en quoi elle consiste et je ne trouve aucune information à ce sujet. Voulez-vous dire que JMP recherche dans le dossier où l'utilisateur a initialement ouvert le fichier .jmpaddin ? Et que recherche-t-il exactement ? Des fichiers .jmpaddin avec des noms différents mais le même identifiant d'extension dans la définition de l'extension ? Ou des informations concernant la version de l'extension dans la définition de l'extension ? Ou encore des fichiers portant le même nom mais dont le contenu a été modifié ?
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.def@hardner Je ne suis pas certain qu'il existe une documentation à ce sujet. Les informations dont je dispose proviennent de mes propres tests et observations, ainsi que d'une discussion avec le support JMP lorsque j'ai constaté que JMP 19 me demandait de vérifier les mises à jour de certains de mes modules complémentaires.
Et oui, si vous allez dans Affichage > Modules complémentaires, vous devriez voir certains des éléments que j'ai décrits… vous devriez voir une section « Source d'installation » ainsi qu'une liste déroulante « Mise à jour »… si la liste déroulante est réglée sur « Rechercher les mises à jour… », JMP surveillera le dossier d'installation indiqué, et il n'est pas facile ni possible de le modifier – pour l'instant.
Je ne sais pas exactement comment JMP effectue la surveillance. Je suppose qu'il s'agit d'un fichier portant le même nom (.jmpaddin) avec une date de modification plus récente ? Mais je peux me tromper… Ma question principale concerne le contrôle de certains éléments.
1. Mon infrastructure de mise à jour automatique est déjà en place ; je ne souhaite donc pas que JMP surveille quoi que ce soit et je veux que ce paramètre soit défini par l’extension elle-même, sans intervention de l’utilisateur.
2. Si je souhaite que JMP effectue une surveillance, je veux contrôler la manière dont il surveille les mises à jour, par exemple en forçant la surveillance d'un dossier PROD, ce qui permettrait à l'utilisateur de télécharger des fichiers .jmpaddin de test sans affecter la surveillance de PROD.
Pouvoir codifier cela via le fichier addin.def me semble la solution la plus logique… et si un utilisateur souhaite vraiment modifier le comportement, l'option Affichage > Modules complémentaires reste disponible. Cependant, l'implémentation actuelle, quelles que soient les règles sous-jacentes, perturbe certains aspects de l'infrastructure que j'ai déjà mise en place et que j'utilise pour le déploiement de ma suite de modules complémentaires.
Est-ce que cela vous aide ?
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defL'activation automatique de la mise à jour par défaut (via un paramètre dans le module complémentaire) pour les modules complémentaires d'entreprise va tout changer !
C’est tellement risqué qu’un utilisateur oublie d’activer la fonction de mise à jour et se retrouve ainsi bloqué avec une ancienne version.
Un paramètre dans le module complémentaire est bien plus efficace qu'un paramètre dans les préférences locales. Comment garantir que 100 % des utilisateurs activeront la fonctionnalité dans leurs préférences locales ?
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defD'après notre expérience :
- un fichier portant le même nom est surveillé
- La mise à jour est déclenchée lorsque le fichier est nouveau (même si la version n'a pas été modifiée).
- La modification d'autres fichiers dans le dossier n'affecte pas le mécanisme
avantage par rapport à UpdateCheck@AddInManager :
Plusieurs modules complémentaires peuvent être mis à jour de manière synchrone.
- Mode silencieux (même si je n'ose pas l'utiliser - c'est bien de savoir quel module complémentaire est mis à jour)
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defÀ l'inverse, je ne veux pas que quiconque utilise la fonction de mise à jour automatique… tant que je n'aurai pas un contrôle total sur les autres aspects de cette mise à jour !
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defMerci @nathan-clark et @hogi . J'ai fait une demande d'assistance pour obtenir plus de détails à ce sujet. Je partage entièrement votre souhait d'avoir la possibilité de contrôler les options relatives à ce comportement.
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defDonc, si @nathan-clark souhaite reprendre le contrôle – en interdisant la sélection manuelle de l'option –, alors une fonction « forcer les paramètres » sera utile.
Dans mon cas, une simple sélection des paramètres par défaut suffira.
Lorsque des modules complémentaires sont installés depuis SharePoint et synchronisés avec le OneDrive local, chaque utilisateur disposera de son propre chemin d'installation.
Lors de l'installation à partir d'un lecteur réseau, il peut être judicieux de forcer la mise à jour automatique à utiliser un chemin par défaut.
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defTout à fait d'accord ! C'est en partie pour cela que je souhaite que cela soit codable via le fichier addin.def.
Ce qui me déplaît le plus, c'est le changement de la source d'installation... comme votre SharePoint @hogi , si l'installation concerne une version bêta, cette source peut être modifiée pour pointer vers l'emplacement bêta... donc les utilisateurs ne seraient pas avertis si une nouvelle version de production était créée.
Ce genre de petits détails peut potentiellement perturber les infrastructures/voies existantes 
Heureusement, je ne pense pas que l'ascenseur soit très difficile à alimenter pour plusieurs voies.
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defSi vous avez téléchargé le fichier depuis SharePoint puis l'avez ouvert depuis votre dossier « Téléchargements », la mise à jour automatique ne fonctionnera pas, car elle suppose que l'emplacement d'installation est celui indiqué. Le client avec lequel je travaillais espérait, je crois, permettre de spécifier un emplacement distant pour la recherche de mises à jour (son serveur d'entreprise, SharePoint, etc.). Quel que soit le mode d'ouverture du fichier, cet emplacement officiel aurait été défini, par exemple dans le fichier addin.def, comme lieu de recherche des mises à jour. Ainsi, aucune erreur ne serait signalée si cet emplacement était inaccessible.
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.def@hardner, vous pouvez synchroniser votre SharePoint pour que le dossier apparaisse dans votre explorateur de fichiers comme s'il était local. Dans un emplacement SharePoint, il y a souvent un bouton « Synchroniser » qui permet de l'ajouter comme dossier local synchronisé, accessible comme n'importe quel autre dossier de votre disque.
S'ils téléchargent le fichier directement, vous avez raison, cela peut également « rompre » le chemin prévu.
Je ne peux pas affirmer avec certitude que ce soit le cas partout, mais c'est comme ça que ça fonctionne chez nous… Il y a peut-être aussi un bouton « Créer un raccourci OneDrive ». Il fait quelque chose de similaire, mais j'évite de l'utiliser (j'en reparlerai).
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defCompris. J'utilise la synchronisation, mais je suis également membre de comptes SharePoint qui ne me permettent pas de synchroniser. Ma première idée serait de télécharger un fichier comme celui-ci pour l'avoir sous la main. Quoi qu'il en soit, je soulignais surtout que cette logique n'est utile que si les utilisateurs ouvrent le fichier .jmpaddin directement depuis l'emplacement officiel où les mises à jour apparaissent. Or, je ne vois pas comment imposer cette méthode plutôt que le téléchargement, le partage par e-mail, etc.
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defOui, c'est logique. Je pense que la démarche de JMP est très pertinente et pourrait simplifier considérablement les choses… Ce qui m'a surtout poussé à changer, c'est que leur implémentation est incompatible avec la mienne ! Mais avec les bons mécanismes de contrôle, je pourrais peut-être abandonner une partie de mon infrastructure pour m'appuyer sur celle de JMP !
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defQue diriez-vous de : AddinLoad.jsl ?
- Remplacer le fichier d'installation par le fichier standard de l'entreprise
- Si Test-Dir : afficher un avertissement indiquant qu'une version de test est installée ; suggérer à l'utilisateur d'installer la version officielle depuis le site officiel.
- si InstallationDir=Download -> désactiver la mise à jour
Il nous suffit de trouver où l'information est enregistrée, puis de la lire, d'y accéder et de la modifier.
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defLes fichiers addinload peuvent être capricieux selon leur utilisation et l'ordre d'installation des éléments par JMP. J'ai construit mon système à partir de bibliothèques incluses uniquement lorsque j'en ai besoin… mais j'ai déjà utilisé addinload. Mon système est par ailleurs très stable – du moins jusqu'à ce que JMP redonne le contrôle à l'utilisateur !
En résumé, pour ma part, j'utiliserai les produits JMP s'ils sont meilleurs que les miens, mais je ne veux pas être forcé d'utiliser les produits JMP.
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defAh, voilà :
Open(
"$USER_APPDATA_ALL/addinRegistryV2.xml",
XML Settings(
Stack( 0 ),
Row( "/AddinReg/Addins/Addin/@id" ),
Col(
"/AddinReg/Addins/Addin/@id",
Column Name( "Addin.id" ),
Fill( "Use Once" ),
Type( "Character" ),
Format( {"Best", Use thousands separator( 0 ), 15} ),
Modeling Type( "Continuous" )
),
Col(
"/AddinReg/Addins/Addin/@timeStamp",
Column Name( "Addin.timeStamp" ),
Fill( "Use Once" ),
Type( "Numeric" ),
Format( {"Best", Use thousands separator( 0 ), 15} ),
Modeling Type( "Continuous" )
),
Col(
"/AddinReg/Addins/Addin/@installSource",
Column Name( "Addin.installSource" ),
Fill( "Use Once" ),
Type( "Numeric" ),
Format( {"Best", Use thousands separator( 0 ), 15} ),
Modeling Type( "Continuous" )
),
Col(
"/AddinReg/Addins/Addin/@installSourceTimeStamp",
Column Name( "Addin.installSourceTimeStamp" ),
Fill( "Use Once" ),
Type( "Numeric" ),
Format( {"Best", Use thousands separator( 0 ), 15} ),
Modeling Type( "Continuous" )
),
Col(
"/AddinReg/Addins/Addin/@autoUpdate",
Column Name( "Addin.autoUpdate" ),
Fill( "Use Once" ),
Type( "Numeric" ),
Format( {"Best", Use thousands separator( 0 ), 15} ),
Modeling Type( "Continuous" )
),
Col(
"/AddinReg/Addins/Addin/@updatePrompt",
Column Name( "Addin.updatePrompt" ),
Fill( "Use Once" ),
Type( "Character" ),
Format( {"Best", Use thousands separator( 0 ), 15} ),
Modeling Type( "Continuous" )
)
),
XML Wizard( 0 )
);
Il vous suffit de supprimer l'étiquette autoUpdate et vos collègues devront se fier à votre implémentation à toute épreuve.
Vous pourriez installer un module complémentaire UpdateCheck qui vérifie les paramètres, les ajuste et signale les erreurs si elles sont incorrectes.
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defOh, intéressant @hogi ! Ça a l'air d'être une solution de contournement que je devrais tester Le support JMP m'a aussi fourni du JSL qui me permet de désactiver ce paramètre lors des mises à jour ; il faut que je l'essaie aussi.
Names Default To Here( 1 );
/* Installing Add-In:
Open( Add-In to open,
<CHECK for="" updates="">
, // "always" will check for updates at startup and while jmp is running
<UPDATE prompt="">
) // whether or not the add-in will silently update or prompt first */ Open( \\NetworkLocation\addins\test.jmpaddin, Check For Updates( "never" ), Update Prompt( 0 ) );
</UPDATE>
</CHECK>
Re : Les options de mise à jour automatique des modules complémentaires sont codifiées dans addin.defAh, merveilleux !
Idéal pour configurer un script batch afin de mettre à jour la mise à jour :
Exécutez tous les programmes d'installation des modules complémentaires et ajustez les paramètres.
