Publication scbatch et choix de skin

Bonjour,

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 :

    <scServer url="http://127.0.0.1:8080/scenariserver4.2/s/u/batch" user="XXXXX" password="YYYYY" failProperty="error" haltOnError="false" verbose="true">
        <generate wspCode="MonCodeAtelier" rootItemUri="MonCheminVersRacine.publi" destPath="MonCheminDestination">
            <type code="auroraW">
                <param key="skin" value="Le_codeSkin_DeMonSkin"/>
            </type>
        </generate>
    </scServer>

Pouvez-vous me dire si j’ai oublié un paramètre ?

Merci d’avance
Franck

Bonjour Franck,
La spécification du skin me semble être correcte dans ce que tu as posté.
Pistes :

  • Erreur dans le code du skin ;
  • Le skin n’est pas activé dans ce contexte, ou absent pour ce générateur.

Coté interface, dans le même atelier, pour le même item et pour le même générateur, la sélection de ton skin fonctionne ?

Antoine
Kelis

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

La particularité éventuelle c’est que je suis sur un modèle dérivé d’Opale mais le code du generator pointé par le skin dans styler est bien auroraW

Bonjour Franck,
Je viens de retester avec succés :

<scServer url="http://localhost:8080/scserver/s/u/batch" user="xxx" password="xxx" haltOnError="no" verbose="true" >
			<sequence haltOnError="false">
				<generate wspCode="Opale" rootItemUri="/_web.publi" destPath="XXXtest">
					<type code="auroraW">
						<param key="skin" value="~OpaleSkinSunrise3-8"/>
					</type>
				</generate>
			</sequence>
		</scServer>

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 :slight_smile:

Antoine
Kelis

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 ?

A+
Franck

Bonjour Franck,
Tu dois appliquer la règle suivante pour reconstruire cet identifiant :
SCENARI4.2- :

identifiantComletDuSkin = ~[codeSkinSet][versionMajeureSkinSet]-[versionMediumSkinSet]_[versionMineureSkinSet]

SCENARI5.0+ :

identifiantComletDuSkin = ~[codeSkinSet][versionMajeureSkinSet]-[versionMediumSkinSet]

Exemple :
image
correspond à l’identifiant : ~monSkinPerso1-4

Ok merci pour le retour
J’ai le skin suivant :


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.

A+
Franck

Tu peux m’envoyer ton skin compilé en mail privé ?

Re Bonjour,

J’ai fini par trouvé le bon format dans le cas de version contenant une version mineure c’est

identifiantComletDuSkin = ~[codeSkinSet][versionMajeureSkinSet]-[versionMediumSkinSet]_[versionMineureSkinset]

Le fait de t’envoyer le skinpack m’a interpellé et ça a payé.

Un grand merci pour le soutien
Franck

1 « J'aime »

Différence SCENARI4.2 et SCENARI5.0 ça :slight_smile:
Je précise celà dans mon message plus haut

1 « J'aime »

Petite précision :

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.

Bonjour Xavier, Sylvain,

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.

Amicalement
Franck

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.