2010-09-27 25 views
7

Je suis intéressé par Qooxdoo comme framework de développement web. J'ai téléchargé le SDK et l'ai installé dans un emplacement central sur mon PC comme je m'attends à l'utiliser sur plusieurs projets. J'ai utilisé le script create-application.py pour créer une nouvelle application de test et ajouté tous les fichiers générés à mon système de contrôle de version. Je voudrais pouvoir collaborer avec d'autres développeurs sur d'autres PC. Ils sont susceptibles d'avoir le SDK installé dans un endroit différent. Les fichiers générés automatiquement dans Qooxdoo semblent inclure le chemin du SDK à la fois dans config.json et generator.py: si le chemin du SDK se déplace, le script generator.py cesse de fonctionner. generator.py ne semble pas être trop un problème car il regarde config.json pour un chemin mis à jour, mais je ne suis pas sûr de la meilleure façon de gérer config.json.Développement avec Qooxdoo et plusieurs développeurs

Les options que j'ai pensé à ce jour sont:

  1. exclure du VCS, mais il ne semble pas être un script pour régénérer automatiquement, donc cela pourrait être dangereux.
  2. Ajoutez-le au VCS mais demandez à chaque développeur de modifier la ligne de chemin et acceptez qu'il soit éventuellement nécessaire de l'ajuster à chaque fois que des modifications sont fusionnées.
  3. Modifiez config.json comme chemin et une seule ligne 'include' pointant vers un deuxième fichier contenant toutes les informations non liées au chemin SDK.
  4. Utilisez un chemin d'accès relatif au SDK et conservez une copie distincte du SDK pour chaque projet qui l'utilise.

L'approche 1 serait idéale si le script de génération existait; approche 2 est vraiment méchant; Je ne pouvais pas obtenir l'approche 3 pour travailler et l'approche 4 est un peu brouillon car cela signifie que plusieurs copies du SDK jonchaient à propos de l'endroit.

Le SDK Android semble très bien s'en occuper (en utilisant l'approche 1), avec le chemin du SDK dans son propre fichier avec un script qui génère automatiquement ce fichier. Pour autant que je puisse dire, Qooxdoo met beaucoup d'autres informations importantes dans config.json et la seule façon de générer automatiquement ce fichier est de créer un nouveau projet.

Existe-t-il un moyen mieux/recommandé pour faire face à cela?

+0

Je ne comprends pas vraiment 3. Pouvez-vous élaborer? – ThomasH

+0

Dans config.json il y a une section "include", donc pris un dépliant (ne sachant rien de json) et copié le fichier entier à l'exception du chemin QOOXDOO dans un autre fichier et référencé l'autre fichier dans la section include. Ça n'a pas marché. – NPB

Répondre

6

Comme alternative à l'utilisation de liens symboliques, vous pouvez remplacer la macro QOOXDOO_PATH sur la ligne de commande:

./generate.py source -m QOOXDOO_PATH:<local_path_to_qooxdoo> 

(En fonction du shell que vous vous utilisez peut-être appliquer une bonne citation de l'argument -m). De cette façon, chaque programmeur peut utiliser son SDK qooxdoo installé localement. Vous pouvez même supprimer l'entrée QOOXDOO_PATH de config.json pour l'appliquer.

+0

Cela semble presque parfait: je pourrais facilement éditer le script local generator.py afin que l'argument soit ajouté automatiquement et que le QOOXDOO_PATH soit chargé à partir d'un autre script python (avec rien d'autre). Malheureusement, cela ne fonctionne pas sous Windows car le plus haut niveau 'generator.py' utilise' split (':') 'plutôt que' split (':', 1) ', donc les chemins Windows (avec': ' dans eux après la lettre de lecteur se briser et vous obtenez un message d'erreur). Si proche et pourtant si loin ... – NPB

+1

Cela a déjà été réparé dans le coffre :-). Si vous voulez coller avec le 1.2 publié, allez-y et corrigez tool/pylib/misc/ExtendAction.py: 41. – ThomasH

+0

Excellent, merci beaucoup. – NPB

4

Nous travaillons avec un lien symbolique pointant vers le sdk ... config.json contient juste le chemin du lien.

+0

C'est une bonne idée. Comment cela serait-il utilisé pour les développeurs sur Windows? – NPB

+0

Hmmm, pas sûr si cela fonctionne, mais http://technet.microsoft.com/en-us/library/cc753194(WS.10).aspx suggère que la commande mlink devrait vous fournir des liens symboliques sur les systèmes de fichiers Windows NTFS. .. –

+0

notez également que si vous avez un serveur samba, vous pouvez faire le lien symbolique là-bas et les fenêtres penseront qu'il y avait une copie locale de qooxdoo juste là. –