MikeH n'est pas MichaelH (et inversement 
)
Mike est un développeur Alfresco.
Cela dit je pense qu'il parle d'un problème de connexion à la base au sens IP.
Toujours bien vérifier d'ailleurs que MySQL autorise les connexions de type "network" et pas juste en local.
Certaines distributions l'interdisent par défaut.
)Mike est un développeur Alfresco.
Cela dit je pense qu'il parle d'un problème de connexion à la base au sens IP.
Toujours bien vérifier d'ailleurs que MySQL autorise les connexions de type "network" et pas juste en local.
Certaines distributions l'interdisent par défaut.
Euh … si c'était possible elle serait téléchargeable … (j'ai l'impression de rater un truc là).
Pour qu'il y ait une nouvelle nightly il faut obligatoirement :
- Des changements de code.
- Que la compilation passe pour tous les modules et projets.
- Que les tests unitaires passent à 100 %.
Ce qui explique que ce ne soit pas une livraison journalière (même si le processus est lancé chaque nuit).
Et ça ne garantit jamais le bon fonctionnement pour autant … c'est une nightly quoi
Rien n'empêche de compiler une version à la main à partir de HEAD dans tous les cas, mais à condition de lire quasi quotidiennement les logs associés pour limiter les surprises (avec l'entrainement on sait prévoir les "zones de risque" ou différencier les bugs réels des "travaux en cours" qui ne méritent pas un rapport).
Pour qu'il y ait une nouvelle nightly il faut obligatoirement :
- Des changements de code.
- Que la compilation passe pour tous les modules et projets.
- Que les tests unitaires passent à 100 %.
Ce qui explique que ce ne soit pas une livraison journalière (même si le processus est lancé chaque nuit).
Et ça ne garantit jamais le bon fonctionnement pour autant … c'est une nightly quoi
Rien n'empêche de compiler une version à la main à partir de HEAD dans tous les cas, mais à condition de lire quasi quotidiennement les logs associés pour limiter les surprises (avec l'entrainement on sait prévoir les "zones de risque" ou différencier les bugs réels des "travaux en cours" qui ne méritent pas un rapport).
Il y a une page : http://wiki.alfresco.com/wiki/Alfresco_SVN_Development_Environment
Si je devais résumer en quelques étapes :
- Récupérer le source (svn update)
- Positionner les variables d'environnement citées (JAVA_HOME, TOMCAT_HOME, APP_TOMCAT_HOME, JBOSS_HOME, VIRTUAL_TOMCAT_HOME)
- Se placer dans HEAD/root
- Appeler "ant" avec la cible associée (pour les débutants, je conseille de juste se concentrer sur "ant build-tomcat")
- Se servir un café (c'est assez rapide, même sans avoir une machine de compétition - compter 5 à 10 minutes en gros)
- En option : prendre un air super concentré en ayant l'air de lire tout ce qui défile
Si on veut tricher, on peut se contenter de déposer les fichiers war dans l'arborescence d'une installation qui fonctionne (typiquement /tomcat/webapps). MySQL est optionnel pour des tests rapide où Derby est suffisant.
Une fois que ça marche on se fait un petit script pour automatiser tout ça, et on peut compiler quand on en a envie.
Lisez bien la page du wiki, tout y est !
Je le fais assez souvent, et il est assez rare que ça ne compile pas (et à nouveau la raison est souvent dans le log du SVN - la bonne pratique est donc de lire le log avant pour savoir si il est intéressant de lancer la compilation parce qu'un correctif spécifique ou parce qu'une nouvelle fonctionnalité s'y trouve). Sinon l'erreur est assez parlante … ou pas
La portion qui pose quelques soucis se trouve coté scripts (typiquement le problème que tu as rencontré) car ils sont plus difficile à couvrir avec les tests unitaires (on est à plus de 1600 tests lancés après chaque compilation pour assurer un minimum de qualité). Mais le principe est simple : quand une version pose problème à cause d'un oubli, on ajoute le test correspondant pour éviter que ça se reproduise plus tard, et donc à force la qualité augmente (il y a une personne qui passe beaucoup de temps sur ce sujet - et tant mieux).
Tu sais (presque) tout !
Si je devais résumer en quelques étapes :
- Récupérer le source (svn update)
- Positionner les variables d'environnement citées (JAVA_HOME, TOMCAT_HOME, APP_TOMCAT_HOME, JBOSS_HOME, VIRTUAL_TOMCAT_HOME)
- Se placer dans HEAD/root
- Appeler "ant" avec la cible associée (pour les débutants, je conseille de juste se concentrer sur "ant build-tomcat")
- Se servir un café (c'est assez rapide, même sans avoir une machine de compétition - compter 5 à 10 minutes en gros)
- En option : prendre un air super concentré en ayant l'air de lire tout ce qui défile
Si on veut tricher, on peut se contenter de déposer les fichiers war dans l'arborescence d'une installation qui fonctionne (typiquement /tomcat/webapps). MySQL est optionnel pour des tests rapide où Derby est suffisant.
Une fois que ça marche on se fait un petit script pour automatiser tout ça, et on peut compiler quand on en a envie.
Lisez bien la page du wiki, tout y est !
Je le fais assez souvent, et il est assez rare que ça ne compile pas (et à nouveau la raison est souvent dans le log du SVN - la bonne pratique est donc de lire le log avant pour savoir si il est intéressant de lancer la compilation parce qu'un correctif spécifique ou parce qu'une nouvelle fonctionnalité s'y trouve). Sinon l'erreur est assez parlante … ou pas
La portion qui pose quelques soucis se trouve coté scripts (typiquement le problème que tu as rencontré) car ils sont plus difficile à couvrir avec les tests unitaires (on est à plus de 1600 tests lancés après chaque compilation pour assurer un minimum de qualité). Mais le principe est simple : quand une version pose problème à cause d'un oubli, on ajoute le test correspondant pour éviter que ça se reproduise plus tard, et donc à force la qualité augmente (il y a une personne qui passe beaucoup de temps sur ce sujet - et tant mieux).
Tu sais (presque) tout !
