- Cantharella-devel - mailman.cloud.codelutin.com

Re: [Cantharella-devel] [Cantharella] Réunion de démarrage
by Adrien Cheype Nov. 12, 2012

Nov. 12, 2012

Bonjour, En effet, la commande que je vous ai donné récupère un dépôt vide. Désolé, je n'étais pas aller jusqu'au bout de la procédure. La documentation de sourceforge n'est pas claire à ce niveau car il y a une double documentation : celle pour le système "classique" et celle pour le système "2.0 Beta" (liens commençant par "sourceforge.net/p"). Etant donné que nous utilisons ce dernier système pour le projet Cantharella, la commande est légèrement différente : rsync -av svn.code.sf.net::p/cantharella/code/* . Avec cette commande, vous ne devriez pas rencontrer de problèmes pour récupérer les 14 révisions. Vous trouverez plus d'informations ici (documentation plus dur à trouver que l'autre documentation traitant du même sujet) : https://sourceforge.net/p/forge/documentation/rsync/ Bonne journée, Adrien Le 10/11/2012 05:26, Benjamin POUSSIN a écrit : > On Fri, 09 Nov 2012 17:17:06 +1100 > Adrien Cheype<adrien.cheype(a)ird.fr> wrote: > >>> Nous avons déjà effectué quelques commits sur le projet après la >>> migration de svn. Tenez-vous particulièrement aux 14 commits effectués >>> sur sourceforge ? (Sachant que le svn sourceforge reste disponible) >> Oui, il serait préférable de les intégrer, ces commits traduisent >> certaines évolutions importantes et à terme nous allons supprimer le svn >> de sourceforge et rediriger vers votre forge. >> J'ai fait attention de vous prévenir le plus tôt possible afin d'éviter >> qu'il n'y ait d'autres commits sur le SVN de votre forge. Le plus simple >> serait d'importer les anciens commits de sourceforge (avec la procédure >> que je vous ai fourni) puis de factoriser les 5 commits qui ont été >> effectués par Tony Chemit en un seul. Une simple copie de la version >> actuelle suffira. > Bonjour, > > Le problème est que la procédure décrite ne permet que de récupérer le > repository en r0 c'est a dire lorsqu'il était vide :(. > > les fichiers récupérer par la commande rsync: > > 8 ./locks > 44 ./hooks > 0 ./db/txn-protorevs > 0 ./db/transactions > 4 ./db/revs/0 > 4 ./db/revs > 4 ./db/revprops/0 > 4 ./db/revprops > 40 ./db > 12 ./conf > 112 . > > Sauf erreur de notre part, nous ne pouvons pas avec cette procédure > récupérer le svn de SF :( > -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

1 0

Re: [Cantharella-devel] [Cantharella] Réunion de démarrage
by Adrien Cheype Nov. 9, 2012

Nov. 9, 2012

Bonjour, Mes réponses dans le texte. Le 09/11/2012 04:36, Jean Couteau a écrit : >> Par contre, en regardant de plus près, j'ai remarqué que vous aviez >> récupérés sur votre dépôt SVN seulement la dernière version du SVN de >> Sourceforge. Serait-il possible que vous récupéreriez les commits >> précédents ? > Nous avons déjà effectué quelques commits sur le projet après la > migration de svn. Tenez-vous particulièrement aux 14 commits effectués > sur sourceforge ? (Sachant que le svn sourceforge reste disponible) Oui, il serait préférable de les intégrer, ces commits traduisent certaines évolutions importantes et à terme nous allons supprimer le svn de sourceforge et rediriger vers votre forge. J'ai fait attention de vous prévenir le plus tôt possible afin d'éviter qu'il n'y ait d'autres commits sur le SVN de votre forge. Le plus simple serait d'importer les anciens commits de sourceforge (avec la procédure que je vous ai fourni) puis de factoriser les 5 commits qui ont été effectués par Tony Chemit en un seul. Une simple copie de la version actuelle suffira. > >> Autre détail, les nouveaux tickets d'évolution sont renseignés pour la >> v1. Serait-il possible de garder les mêmes numéros de versions ? C'est à >> dire de laisser les anciens tickets sur la v1 (version actuelle), et que >> les évolutions soient dispatchées entre la v1.1 (actuelle prestation) et >> la v1.2 (future prestation avec fonctionnalités non retenues). > Concernant les versions, je me pose plusieurs questions. Le trunk était > en version 1.0 (il devrait être en version snapshot), et aucun tag n'est > présent sur le svn. > > Nous proposons de faire une release (et donc un tag) 1.0 qui fixe > cantharella dans sa version actuelle. Nous passons ensuite le trunk en > version 1.1-SNAPSHOT et nous effectuons la prestation sur cette version. > A la fin de la prestation, nous faisons une release 1.1, le trunk passe > alors en version 1.2-SNAPSHOT (et nous avons un tag 1.1). > > Les tickets de la version actuelle qui sont clos restent sur la version > 1.0. Les tickets non clos passent sur la version 1.2, les tickets de la > prestation que nous réalisons passent sur la version 1.1. Si des tickets > sont corrigés, nous les passeront sur la version 1.1. > > A la fin de la prestation, resteront sur la version 1.2 (développements > à effectuer), les tickets de bugs non résolus. > > Je ne sais pas si je suis clair dans mes explications. Dans le cas > contraire, je vous propose d'en reparler lors de notre visio de la > semaine prochaine. Vos explications sont très claires. Ok pour suivre cette démarche, elle se base en plus sur des bonnes pratiques de versioning. Bonne journée, A. Cheype -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

2 1

Re: [Cantharella-devel] Utilisation d'hibernate Search pour la recherche
by Adrien Cheype Nov. 9, 2012

Nov. 9, 2012

Re-bonjour, Parfait si vous avez pu vérifier qu'Hibernate Search est le meilleur candidat pour nos besoins. Concernant le choix entre la mise en place par annotations sur les entités ou par programmation, je serais plus d'avis à utiliser les annotations. En effet, le projet Cantharella est déjà très orienté annotation. Que ce soit pour Hibernate ou pour Spring, nous avons toujours essayé de les privilégier et de minimiser au maximum les fichiers de configuration XML (avec aussi un effort de passer par de la configuration par programmation lorsque les annotations ne sont pas possibles). L'utilisation par annotation étant par ailleurs le mode de fonctionnement par défaut d'Hibernate Search, il serait dommage de ne pas en bénéficier. Je comprends bien toutefois l'argument de vouloir centraliser dans une ou plusieurs classes l'ensemble du code se rapportant à Hibernate Search pour des raisons de modularité. C'est souvent l'inconvénient de ces systèmes d'annotations centrés DAO, cependant en contre partie ils ont l'avantage d'offrir une vision claire de l'ensemble des contraintes et fonctionnalités liées au modèle. Actuellement, les classes DAO comportent déjà des annotations d'hibernate/JPA (Hibernate Annotation, Hibernate Validation, javax.persistence) ou même d'autres annotations personnalisées pour des validations métiers. Le fait de rajouter d'autres annotations pour préciser les champs à indexer ne me pose donc pas plus de problème que cela. Les requêtes pourront par contre être factorisées dans des classes à part (par exemple, une classe pour chaque entité) dans un package spécialisé de la couche DAO. Cette question mérite certainement d'être discutée plus amplement. Peut-être pourrions-nous aborder ce point à la prochaine réunion ? Bonne journée, Adrien Le 09/11/2012 05:34, Benjamin POUSSIN a écrit : > Bonjour, > > Il semble que la solution Hibernate Search conviendrait à notre besoin > pour la recherche. > > On peut la mettre en place soit par des annotations sur les entités > soit par programmation. > > Je propose de la mettre en place par programmation, pour que tout le > travail soit à un seul endroit (une classe) et ainsi permettre de > facilement la retirer pour mettre une autre solution si besoin ou > mettre à jour la solution si le modèle évolue sans devoir reprendre > chaque classe d'entité une par une. > > Est-ce que cette solution convient à tout le monde ? > -- Adrien Cheype Ingénieur en Systèmes d'Information Service « Informatique Scientifique et Appui aux Partenaires du Sud » Direction du Système d'Information (DSI) http://www.ird.fr/dsi/ http://www.ird.fr/informatique-scientifique/ INSTITUT DE RECHERCHE POUR LE DEVELOPPEMENT BP A5 - 98848 Nouméa - Nouvelle Calédonie Tél. +687 260 789

1 0

Utilisation d'hibernate Search pour la recherche
by Benjamin POUSSIN Nov. 8, 2012

Nov. 8, 2012

Bonjour, Il semble que la solution Hibernate Search conviendrait à notre besoin pour la recherche. On peut la mettre en place soit par des annotations sur les entités soit par programmation. Je propose de la mettre en place par programmation, pour que tout le travail soit à un seul endroit (une classe) et ainsi permettre de facilement la retirer pour mettre une autre solution si besoin ou mettre à jour la solution si le modèle évolue sans devoir reprendre chaque classe d'entité une par une. Est-ce que cette solution convient à tout le monde ? -- Benjamin POUSSIN -------------------- tél: +33 (0) 2 40 50 29 28 email: poussin(a)codelutin.com http://www.codelutin.com

1 0

Re: [Cantharella-devel] [Cantharella] Réunion de démarrage
by Jean Couteau Nov. 8, 2012

Nov. 8, 2012

Bonjour, Le 30/10/2012 01:12, Adrien Cheype a écrit : > Merci pour la réunion d'hier. Nous avons reçu depuis les notifications > mail qui montre que vous avez commencé à effectuer la migration de forge. Effectivement. > > Par contre, en regardant de plus près, j'ai remarqué que vous aviez > récupérés sur votre dépôt SVN seulement la dernière version du SVN de > Sourceforge. Serait-il possible que vous récupéreriez les commits > précédents ? Nous avons déjà effectué quelques commits sur le projet après la migration de svn. Tenez-vous particulièrement aux 14 commits effectués sur sourceforge ? (Sachant que le svn sourceforge reste disponible) > Autre détail, les nouveaux tickets d'évolution sont renseignés pour la > v1. Serait-il possible de garder les mêmes numéros de versions ? C'est à > dire de laisser les anciens tickets sur la v1 (version actuelle), et que > les évolutions soient dispatchées entre la v1.1 (actuelle prestation) et > la v1.2 (future prestation avec fonctionnalités non retenues). Concernant les versions, je me pose plusieurs questions. Le trunk était en version 1.0 (il devrait être en version snapshot), et aucun tag n'est présent sur le svn. Nous proposons de faire une release (et donc un tag) 1.0 qui fixe cantharella dans sa version actuelle. Nous passons ensuite le trunk en version 1.1-SNAPSHOT et nous effectuons la prestation sur cette version. A la fin de la prestation, nous faisons une release 1.1, le trunk passe alors en version 1.2-SNAPSHOT (et nous avons un tag 1.1). Les tickets de la version actuelle qui sont clos restent sur la version 1.0. Les tickets non clos passent sur la version 1.2, les tickets de la prestation que nous réalisons passent sur la version 1.1. Si des tickets sont corrigés, nous les passeront sur la version 1.1. A la fin de la prestation, resteront sur la version 1.2 (développements à effectuer), les tickets de bugs non résolus. Je ne sais pas si je suis clair dans mes explications. Dans le cas contraire, je vous propose d'en reparler lors de notre visio de la semaine prochaine. Cordialement, Jean Couteau -- Jean Couteau - Code Lutin - www.codelutin.com 12 Avenue Jules Verne, 44230 Saint-Sébastien-Sur-Loire Tel : 02.40.50.29.28 - Port : 06.68.07.29.29

1 0