Cette erreur ne me dit rien comme ça…
Puis-je avoir le JSON de cet item Resource ainsi que le contenu des fichiers associés ?
Merci
EDIT: à priori c’est sans doute car un des fichiers joint (le source LESS et le CSS compilé) a un nom de fichier sans extension. Je ne vois pas trop comment cela pourait se produire après un export de module (car celui ci génère des noms de fichier ad hoc indépendants des noms de fichier uploadés dans l’instance). On doit être dans un cas aux limites non prévu.
Voilà ce que je retrouve en BDD
Je crois avoir trouvé le bon JSON :
{
"name":"Resource",
"action":"upsert",
"data":[{
"res_object":{
"name":"Disposition",
"data":[{
"dis_code":"responsive"
}]
},
"res_type":"CSS",
"res_lang":"FRA",
"res_code":"STYLES",
"res_cached":"0",
"res_file":"52307",
"res_file_compiled":"",
"res_image":"",
"row_module_id.mdl_name":"name"
}]
}
Si vous avez toujours notre code, il s’agit des fichier css addon.css et e****_gen.css.
Ca ne devrait pas être un ID mais un chemin relatif dans le répertoire (dans le répertoire resources en l’occurrence). Genre:
Je soupçonne que c’est un reliquat de l’époque où il y avait le bug (corrigé) qui induisait des disparitions “aléatoires” de certaines ressources.
Serait il possible de forcer la récréation d’un document sur cette ressource STYLES associée à la disposition “responsive” (genre par un upload explicite ou suppression explicite + editer).
Puis de réexporter le module pour voir si ça résoud le pb dans le JSON de cet item de paramétrage
Je ne retrouve pas la ressource associée. Je l’ai supprimé et je retrouverais dans l’historique plus tard si jamais elle était vraiment utile. Visiblement on a perdu cette ressource il y a un moment et on a pas constaté de régression visuelle depuis.
J’ai supprimé depuis le repo le json qui y faisait reference et l’import s’est bien déroulé. Je vous tiens au courant pour la suite de notre montage.
En fait la ressource STYLES de la dispo responsive est livrée vide.
Si elle est pas là il y a peut être un message d’erreur dans les logs mais ça n’a pas d’impact visuel.
Pour la petite histoire c’est un héritage historique de l’époque où il n’y avait pas les thèmes car aujourd’hui c’est plutôt au niveau des “addons styles” du thème qu’on met ses styles spécifiques communs (les styles spécifiques à un objet métier ou un objet externe étant à mettre dans la ressource STYLE associée à l’objet en quetsion).
Bref chargez un fichier vide (ou juste avec un commentaire genre /* Nothing */ pour que ça ne soit pas vide) dans cette ressource globale STYLES (et/ou ne l’associez plus à votre module) et réexportez votre module.
J’ai constaté un comportement étrange que j’essaie de reproduire avec un module moins volumineux:
Je faisais un import du module sans probleme depuis le repository git. Par contre, dès que je commitais depuis simplicité, il virait tous les fichier JSON alors que le paramètre EXPORT_MODULE_EXPLODED est bien activé.
Je vais essayer de détailler d’avantage avec un nouveau module de paramètrage.
Mais là il refuse d’importer depuis GIT :
com.simplicite.util.exceptions.GitException: Cannot pull into a repository with state: MERGING
Alors que le repo ne l’est pas.J’ai testé de plusieurs manière mais c’est très instable.
En synthèse : Quelle est la bonne procédure pour passer d’un module XML aujourd’hui à un module JSON ?
Merci de transmettre une marche à suivre détaillée qui nous permette d’avancer plus rapidement sur le sujet.
Personnellement j’ai basculé de XML à exploded JSON sans pb sur mes modules.
EXPORT_MODULE_EXPLODED à yes via la valeur surchargée:Ensuite vous poussez ce commit sur votre remote origin" (soit directement depuis le bouton “Push” si vous l’avez configuré comme ça et que vous avez les droits pour le faire, soit en passant par un clone externe)
En tout cas pas besoin de refaire un pull ou import sur l’instance. Le repo du module n’est qu’un export de ce que vous avez déjà en local.
J’ai migré notre instance de développement en JSON. Problème, le fichier zip généré a l’export ne s’importe plus. Pouvez vous me dire ce qui ne va pas dans le zip généré (transferé par mail).
Quand j’essaie de l’importer, il essaie et abandonne rapidement sans erreur.
Pour fonctionner par simples fichiers ZIP (au lieu d’exports sur repo Git) je pense qu’il faut aussi mettre le param système EXPORT_MODULE_ARTIFACTS à yes
Je croyais que vous alliez fonctionner via Git ? ce n’est pas le cas ?
Nous avons besoins de générer un zip derrière pour le stocker dans artifactory pour pouvoir le déployer sur n’importe quel environnement.
Le fonctionnement actuel, est que tous les développeurs travaillent sur une machine, le zip est telechargé régulièrement, décompressé, commité dans git, analysé, recompressé et déposé sur artifactory. Nous y ajoutons donc notre propre pom pour builder le projet.
J’ai fait le test d’activer le JSON et ça ne posait pas problème car le fichier xml et le package.json étaient encore présent dans GIT, mais en les retirant, l’import ne fonctionne plus.
OK faites ce que j’indique dans ma réponse précédente = passez EXPORT_MODULE_ARTIFACTS à yes + clear cache global + réexportez votre ZIP
Parmi les “artifacts” en question il y en a un qui est requis dans le cas du mode explosé. Or:
L’artifact requis devra donc être généré dans tous les cas (commit Git ou export ZIP) dans le cas du mode explosé. C’est clairement un bug qu’il ne le soit pas dans le cas du ZIP. Ce sera corrigé dans la prochaine révision.
Mais de toute façon, vu vos process basés sur des exports ZIPs, vous devez de toute façon mettre EXPORT_MODULE_ARTIFACTS à yes car sinon il manquera des choses dans l’export ZIP, à commencer par le pom.xml que vous êtes actuellement obligés de recréer manuellement…
Le problème c’est qu’on utilise ce pom pour notre gestion de conf (build, distribution management et dépendances). Peut-on surcharger ce pom de manière simple ?
Le pom.xml, le README.md et les schemas OpenAPI/Swagger générés dans l’export ZIP et le commit Git ne sont pas utilisés dans les imports. Vous pouvez les modifier/supprimer sans impacts sur les imports.
Par contre le fichier qu’il ne faut pas toucher, s’il est là, c’est le package.json qui contient des infos exploitées pour certains formats, notamment le nouveau format explosé.
Dans la révision qui sera poussée ce soir il sera présent dans le ZIP en format explosé quelle que soit la valeur du param système EXPORT_MODULE_ARTIFACTS
D’accord merci.
A quelle moment il faudrait modifier le pom ? Jusqu’ici il était figé dans notre git, là il se fait écraser à chaque fois car sur notre machine de dev il est “basique” avec le warning suivant
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
ZZZ This file is automatically generated, don’t change it manually! ZZZ
ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
Il ne reprend pas le pom présent dans le zip à l’import ?
Le pom.xml n’a strictement aucune utilité au sein de Simplicité.
Il ne sert qu’en dehors de Simplicité (ex depuis un IDE) => Simplicité agit alors comme un repo Maven pour exposer ses libs embarquées comme des dépendances Maven mais au sein de Simplicité ces libs sont directement dans le classpath de compilation.
Oui pour l’instant en fait ça ne pose problème que parce qu’on va recuperer le contenu du zip de notre machine partagée et ça écrase notre pom. Merci pour l’info
Toujours des problèmes a l’import, archive transmise par mail. Pas de réaction a l’import de zip.
Via GIT :
2021-02-16 17:05:02,053 ERROR [com.simplicite.util.engine.Interface] SIMPLICITE|http://c5cb3c722130:8080||ERROR|designer|com.simplicite.util.engine.Interface|importModule||Event: Module: NAMe: Missing XML, JSON or YAML file for module configuration
L’antivirus GMail m’empèche de télécharger le ZIP… bizarre
Mais de toute façon, comme dit plus haut, il y a des changements notables dans la version 5.0.20 qui sera poussée cette nuit. Donc autant tester ça demain sur de bonnes bases.
Nous sommes bien en 5.0.20.
Toujours le même log que dans le message précedent. Voilà la structure du repo ainsi que le contenu du package.json:
Le contenu du package.json indique que ce ZIP n’a pas été exporté depuis une 5.0.20.
Il devrait être du type:
{
"date": "Fri Feb 28 22:02:50 CET 2020",
"name": "Demo",
"format": "json",
"files": ["configuration/"],
"repository": {},
"version": "5",
"dependencies": {"Simplicite": "5"}
}
A noter le configuration/ dans files.
Commencez donc par refaire l’export ZIP de votre module depuis une 5.0.20