J’ai paramétré, sur un serveur 4.2, un fichier build.xml pour lancer la publication d’un module. Il s’agit d’une publi web auroraW pour laquelle je voulais utiliser un skin donné. La publication se fait bien mais avec le skin Aurora par défaut et non le skin que je lui ai indiqué.
Dans le build.xml j’ai, au contenu « réel » près, ceci :
Bonjour Antoine,
Le skin est bien activé dans l’atelier et fonctionne quand on le lance depuis l’interface de scenariChain quand au code du skin je suis allé sur l’atelier styler puis copier/coller de l’attribut codeSkin du skinset, Donc je ne vois pas où j’aurais pu me trompé.
Bizarre
Je pense que ton identifiant de skin n’est pas correct. C’est en fait un identifiant légèrement plus complet que le code que tu vois dans le skinset, intégrant la version. Exemple pour le skinset de code ‹ OpaleSkinSunrise › en version 3.8 : ~OpaleSkinSunrise3-8.
ps : on essaiera de faire apparaitre ce code complet d’une façon ou d’une autre dans le future scStyler5.0. Difficile en effet d’inventer cette syntaxe
Bonjour Antoine,
Ok pour l’idée que ça soit le ode qui soit mauvais, mais du coup comment je sais quel est le bon ? on trouve ça dans le skinset qqpart ?
En suivant ton exemple, j’ai entré le code ~xristalUnisciel0-2
Et toujours pas de publi avec le bon skin
J’ai tenté sur le même modèle d’utiliser ~xristalUnisciel0-2-1 puisqu’il y a version mineure mais même résultat.
Tous ces services sont bien des services dits couramment « REST » qui sont documentés dans le code java directement.
Mais pour nous, éditeur de Scenari, ces services ne constituent pas une API, au sens où nous ne nous engageons pas à ce que les entrées/sorties de ces services soient stables dans le temps. Nous considérons ces services comme des mécaniques d’échanges de données internes qui peuvent évoluer à tout moment.
Ce que dans Scenari nous positionnons comme des APIs au sens des interfaces publiques pour lesquelles nous essayons de préserver « au maximum » la compatibilité sont :
le modèle SCENARIbuilder,
la couche cliente des services batch.
Tout le reste peut bien évidemment être utilisé « en direct » mais nous ne nous engageons à aucune compatibilité ascendante. Nous ne souhaitons donc pas en maintenir une documentation « publique », au delà de celle intégrée au code java (en libre accès), car cela serait contradictoire.
Merci pour vos réponses et précisions respectives. Je pense que vos deux interventions sont utiles car d’un coté ça donne une méthode pour retrouver l’information et de l’autre ça met en garde sur le fait que ça puisse évoluer dans le temps.
Ce n’est qu’une précision mentionnant que ce que tu appelles API n’en est pas une pour nous, au sens d’une interface « publique ». Ce sont de simples services REST internes, qui peuvent néanmoins être utilisés, mais nous ne nous engageons pas à les maintenir dans le temps.