Discussion :

[psykoleouf]

Bonjour,

Environement : Solaris, Continuum 1.0.3, Maven 2, Pom V4.0.0

I - Nous avons tenté l'ajout d'un projet maven 2 dans continuum. J'ai donné l'url de mon pom.xml root du projet sur CVS. Les différents projets se sont bien ajoutés à ceux déjà existants mais pas dans la version désirée.
Il existait déjà des projets en version 6.7-SNAPSHOT, mais les nouveaux projets ajoutés étaient également en version 6.7-SNAPSHOT au lieu de 5.1.9 comme décrit dans le pom.xml root et les différents pom.xml du projet.

Y aurait-il une modification à faire dans la base Derby de continuum ? Ou autre chose ?

II - Avec cette mauvaise manip, nous avons voulu supprimer les nouveaux projets mal versionnés mais pour certains des erreurs surviennent du type :
javax.jdo.JDOUserException: One or more instances could not be deleted
Surement un bug de la version, mais nous n'avons pas le droit de mettre en "production" des betas.

Existe t-il un moyen de supprimer proprement ces projets mal versionnés (Base, répertoire build ou working) ?

III - Nous pensions reprendre une sauvegarde du répertoire continuum datant du 29/09/07, mais depuis des commits sur CVS ont été effectués.

Existe t-il un moyen (si on ne peut pas supprimer proprement ces projets mal versionnés) de revenir dans la version continuum du 29/09 tout en gardant les sources actuelles ?

Ca fait beaucoup de questions pour un post Désolé

Merci d'avance pour vos réponses

[evenisse]

I - Nous avons tenté l'ajout d'un projet maven 2 dans continuum. J'ai donné l'url de mon pom.xml root du projet sur CVS. Les différents projets se sont bien ajoutés à ceux déjà existants mais pas dans la version désirée.
Il existait déjà des projets en version 6.7-SNAPSHOT, mais les nouveaux projets ajoutés étaient également en version 6.7-SNAPSHOT au lieu de 5.1.9 comme décrit dans le pom.xml root et les différents pom.xml du projet.

Y aurait-il une modification à faire dans la base Derby de continuum ? Ou autre chose ?

As-tu defini un tag ou une branche CVS pour ton projet?

II - Avec cette mauvaise manip, nous avons voulu supprimer les nouveaux projets mal versionnés mais pour certains des erreurs surviennent du type :
javax.jdo.JDOUserException: One or more instances could not be deleted
Surement un bug de la version, mais nous n'avons pas le droit de mettre en "production" des betas.

Existe t-il un moyen de supprimer proprement ces projets mal versionnés (Base, répertoire build ou working) ?

C'est un des gros problèmes de la version 1.0.3.
Le seul moyen "propre" est de faire quelques DELETE dans la base en respectant les foreign keys, mais ce n'est pas très simple.
La version 1.1 finale sera dispo dans quelques jours.

III - Nous pensions reprendre une sauvegarde du répertoire continuum datant du 29/09/07, mais depuis des commits sur CVS ont été effectués.

Existe t-il un moyen (si on ne peut pas supprimer proprement ces projets mal versionnés) de revenir dans la version continuum du 29/09 tout en gardant les sources actuelles ?

si tu récupères le backup, Continuum fera un build de tous les projets afin de récupérer la dernière version des sources. Si tu ne veux pas ce build, il te suffit de lancer un "cvs update" dans le working directory de chaque projet.

[psykoleouf]

I - Oui : une branche V5_branch_XXX basée sur un tag en version 05-XXX. Et on veut intégrer tous les projets de cette branche. L'info 6.7-SNAPSHOT que continuum récupère concerne une version 6 (V6_Branch_XXX, 06-XXX)

Où continuum va t-il chercher l'info de version pour les projet Maven2 que l'on rajoute ? Est ce dans les pom.xml ou ailleurs ?

II - On a de nouvelles evol à intégrer, donc la génération de notre cassette (gros package de plusieurs projets) est repoussée à une semaine. Ca me laisse le temps de régler ce problème. De toute facon le temps qu'on fasse accepter l'install de la nouvelle release, il se sera écoulé plus d'1 semaine
Je vais donc essayer du coté du nettoyage de la base. Actuellement, on utilise les jars derbytools-10.1.2.1.jar et derby-10.1.2.1.jar pour se connecter à la base derby. J'ai recup le fichier package.jdo contenu dans continuum-model-1.0.3.jar pour avoir le 'modèle de base de donnée'.

N'y a t-il pas un moyen plus pratique pour accéder à la base derby de continuum ?

III - Je laisse tomber l'idée de recup de la backup, je l'ai fait hier soir et il manque trop de projets ...

[evenisse]

I- Continuum récupère la version dans le pom checkouté, vérifie dans le working directory.

II- Pour l'accès à la base, tu peux utiliser un client graphique, par exemple SquirrelSQL: http://squirrel-sql.sourceforge.net/

[psykoleouf]

Bon nous n'avancons pas, nous nous enfoncons Le serveur continuum ne veut plus démarrer. enfin il démarre : [INFO] The application server has started.
Mais j'ai une pile java avant dont voici deux extraits :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Error while deploying application 'continuum-plexus-application-1.0.3.jar'

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
Caused by: java.lang.SecurityException: sealing violation: package org.apache.derby.iapi.services.crypto is sealed

Avec une recherche google je tombe la dessus :
http://www.nabble.com/Problems-with-...-t3564887.html

Mais je ne vois pas trop de quoi il parle ... Le problème doit surement venir de derby ... Avez vous des idées ?

[evenisse]

As-tu conserver une connexion ouverte avec un client SQL externe?
La version embedded de derby n'accepte qu'un seul client à la fois (Continuum ou un client SQL)

[psykoleouf]

J'avais oublié ce post en cours Je vais faire un petit résumé, ca peut en intéresser certains.

I - Au problème de connection à la base, il s'agissait bien d'un process derby bloqué. Si l'histoire du process bloqué persiste, regardez du côté des fichiers db.lck et dbex.lck dans /continuum-1.0.3/apps/continuum/database. Le lock derby à l'air de s'opérer dans ces fichiers également. Nous, on a bidouillé. Evenisse pourra peut etre nous en dire d'avantage.

II - On a effectué des modifs dans les pom.xml de tous les projets et plus précisément dans la balise <scm>. Pour le pom root du projet, on a rien touché :
<scm>
<connection>scm:cvsxx: xxx: xxx@xxx:/logiciels/XXX:NomProjet</connection>
<developerConnection>scm:cvsxx: xxx: xxx@xxx:/logiciels/XXX:NomProjet</developerConnection>
<url>http://ipserver/viewcvs/viewcvs.cgi/?cvsroot=NomProjet</url>
<tag>nom_de_la_branche</tag>
</scm>

Et dans tous les autres pom des projets fils :

<scm>
<tag>nom_de_la_branche</tag>
</scm>

Ainsi à l'ajout des projets, continuum ajoute tout de suite les infos de la branche en base derby (Ce qui se faisait à la main en base avant )

III - Sinon pour l'ajout du projet, on est passé par FTP. Upload du projet à jour dans un répertoire (ici temp591) du serveur continuum. Dans le champ M2 POM Url : ftp://login:motdepasse@163.xx.xx.xx/temp591/pom.xml .On indique le chemin jusqu'au pom root du projet. A ce moment les projets sont bien ajoutés et dans les bonnes versions même après compilation. C'est gagné

Q1 :Sinon, on a toujours 2-3 projets qu'on arrive pas a supprimer. Apparemment, il s'agit d'entrée dans la table BuildDefinition. Comme si, quand on veut sup un projet qui est dans la queue serait impossible ? Suffit t-il alors de suppriemr cette ligne pour pouvoir supprimer le projet ? Par ex : une des erreurs est la suivante :
Delete request failed: DELETE FROM BUILDDEFINITION WHERE ID = ?
DELETE on table 'BUILDDEFINITION' caused a violation of foreign key constraint 'PROJECT_BUILP8_FK2' for key (532). The statement has been rolled back.]

On recupère l'id 532 du build et on fait un DELETE FROM BUILDDEFINITION WHERE ID = 532 ?

Q2 : J'aurais aussi une question concernant les schedules : Peut t-on via la balise <scm> indiquer le schedule à utiliser pour les projets ?

PS : Sinon j'ai vu que la version 1.1 était sortie On va le plus vite possible faire une demande client pour validation et fini les soucis

[evenisse]

Q1: Il ne faut pas confondre build definition et build result dans tes requetes SQL

Je penses qu'il faudra que tu fasses des delete dans plus d'une table, probablement (BUILDDEFINITION ET BUILDRESULT)

Q2: non. pourquoi voudrais-tu celà?

PS: oui, je conseille vraiment de passer à la 1.1

[psykoleouf]

OK pour la suppression buguée des projets mal versionnés, je laisse tomber. Lors de l'install de la version 1.1, un grand nettoyage sera effectué

Q2 : dans continuum apres l'ajout d'un projet, chaque projet fils apparait dans la liste des projets(afin de pouvoir buildé tel ou tel projets indépendemment). Le pb est le suivant : par défaut le schedule default (build toute les heures normalement) est affecté au nouveau projet. Si je veux que tous mes projets d'une meme version soit lié à un schedule branch_V5_Outillee , par exemple, je suis obligé de le faire projets par projets ? (77 projets par version)

[evenisse]

Q2: ce problème sera résolu lors de la migration vers Continuum 1.1 car dans la 1.1, tu peux définir les build definitions au niveau du groupe de projet donc à un seul endroit.