Extension VSCODE et Certificat autosigné

Support
47

En fait, même en passant par un clone GIT j’ai un problème avec le pom.xml généré.

Initialement

<maven.compiler.source>11</maven.compiler.source>
    <maven.compiler.target>11</maven.compiler.target>

cause une erreur de version sur le plugin maven.compile.

Dans la doc maven ils indiquent de mettre dans ce tag la dernière version du compilateur Java pour aller chercher les bonnes versions de plugin. Je n’ai pas l’impression que 11 soit une version de compilateur Java ?

En tout cas quand je remplace par 1.8 je n’ai plus d’erreur, mais je ne suis pas sensée modifier ce pom …

48

Rebonjour c’est encore moi,

Après avoir démarré en mode debug et paramétré VSCode avec un clone GIT, je me heurte à un nouveau problème.
Le serveur n’est accessible qu’en HTTP tandis que VSCode semble devoir passer par socket.
Y a-t-il une alternative ou est-ce que c’est fichu ? :slight_smile:

Merci !

49

La communication entre VSCode et une instance Simplicité via l’extension se fait exclusivement en HTTP(S) (= appels d’API).

Donc s’il y a un pb de communication par un autre canal ça n’a à priori rien à voir avec l’extension.

50

Non je n’utilise pas l’extension comme il y a un bug.
Je passe par un clone GIT, c’est la même chose ?

51

La communication avec les repos Git d’une instance Simplicité se fait en Git over HTTP(S), cf. l’URL de clone.

52

Il faut peut-être que j’ouvre une connexion SSH alors, je vais essayer

53

Une instance Simplicité n’expose pas ses repos Git over SSH, uniquement over HTTP(S)

54

PS: La seule chose qui utilise autre chose que HTTP(S) c’est le remote debugging (= un protocole ad hoc spécifique à Java via sockets)

55

Bin c’est du remote debugging que je veux faire justement

56

Ah ok désolé (retour de congés j’avais perdu le fil). Le remote debug est un mécanisme purement Java, rien de spécifique à Simplicité. Il faut ouvrir le port configuré (par défaut 8000) et autoriser la communication TCP sur ce port.

Si cette communication n’est pas possible il n’y a pas à ma connaissance de solution. A confirmer avec un expert Java qui saura dire s’il est possible de faire autrement (ex: tunneliser en HTTP(S) : ce qui est en général interdit en entreprise car assimilé à un usage “douteux”).

Sinon il faut travailler en local (remote debug sur container Docker en localhost, ou lancement d’un Tomcat local avec la webapp = approche “traditionnelle”).