Open coder-pour-changer-de-vie opened 8 months ago
Bonjour,
Bienvenue sur le projet! vous pouvez tout à fait y contribuer en proposant des PRs pour y apporter des petites corrections/évolutions.
Le projet est organisé autour de 3 dépôts git distincts :
Une documentation est présente mais est plus portée sur l'aspect fonctionnel de l'application (installation, configuration, etc.), mais peu finalement autour du développement en lui même. Vous pouvez déjà regarder la documentation portée par le module gn_mobile_core
dans le répertoire docs/. La documentation s'appuie sur le format AsciiDoc (plus riche et complet que Markdown) ainsi que dans le répertoire docs/ dans le module gn_mobile_occtax
.
Pour commencer, il faut donc cloner à minima le dépôt git du module "Occtax" :
git clone git@github.com:PnX-SI/gn_mobile_occtax.git
cd gn_mobile_occtax
git checkout develop
Comme il s'appuie sur des sous-modules git, il faut aussi les récupérer via la commande suivante :
git submodule update --init --recursive
Les liens symboliques seront automatiquement résolus.
Au niveau de l'environnement de travail, je préconise :
Au niveau des contributions et de l'organisation des branches :
master
et develop
. La branche master
reflète la dernière release "officielle" (ici 2.6.2) et on va retrouver les tags des différentes versions selon l'approche semver. La branche develop
reflète les versions snapshots ou future RC (avec les tags correspondant).develop
depuis une "feature branch" (par exemple : feature/ma_contrib
).master
. La branche develop
est mise à jour soit en "cherry-pickant" la ou les corrections (si develop
a bien divergé par rapport à master
), soit via un "rebase" par rapport à master
.gn_mobile_occtax
. Il faut donc cloner séparément les modules gn_mobile_core
et gn_mobile_maps
en respectant ce qui est décrit ci-dessus.gn_mobile_occtax
peut se faire via le script ./upgrade_submodules.sh
Actuellement le projet s'appuie au niveau du tooling sur gradle en version 7.4.2 et cible l'API 33 coté Android. Un travail est en cours pour migrer vers les dernières versions.
Voilà pour un premier début :)
Je n'ai pas souvenir que des propositions d'évolutions fonctionnelles aient été discutées ?
De quelles évolutions s'agit-il ?
Si vous faites un fork, il faudra suivre les évolutions que nous faisons par ailleurs dans Occtax-mobile et GeoNature, donc cela sera complexe et coûteux pour vous. Très dommage il me semble.
Bonjour @camillemonchicourt et @sgrimault et merci pour ce retour.
Je reprends sur le projet (partie mobile) et je viens de passer en version 2.14.0 côté serveur (une update est sortie hier je crois en 2.14.1).
Oui je comprends et en effet c'est dommage, je n'ai pas la trace des demandes car ce n'est pas moi qui les ai formulé.
Je dois réaliser un ensemble d'évolutions demandées spécifiques à un client, qui sont actées avec une réalisation au plus tôt.
La decision de forker est pour avancer rapidement sur ces points, en autonomie et pour ne pas rentrer en conflits avec la vision principale du projet, avec un eventuel refus d'une fonctionnalité ou bien des délais trop long d'intégration pour le client.
L'idée est nécessairement de minimiser l'impact pour rester aligné avec les prochaines update de l'application mobile, tant que faire ce peut, et pourquoi pas soumettre certaines fonctionnalités plus tard.
Mais actuelement le temps manque, et la souplesse d'avancer en parralèle à court terme a été préféré, étant donnée que l'application mobile à un cycle d'évolution plus long que la partie serveur.
Ce n'est en effet pas un bon choix, mais un compromis au regard du contexte.
@sgrimault : je vais me familiariser avec l'utilisation des sous modules, merci encore.
Je pars sur la version 2.6.2, en ayant bien noté la 2.7.0-RC7 en pre-release.
Je vais me pencher dans le code (avec prise en main de Kotlin par la même occasion) pour me familiariser avec tout ça.
Bonne journée ! Nicolas.
Bonjour,
premier point : je ne suis pas expert Kotlin, ni Android natif :-)
Nous souhaitons apporter quelques modifications d'ergonomie et donc compiler l'application en partant de zéro.
Nous le faisons car les modifications proposées n'ont pas été acceptées en tant qu'évolution dans la roadmap, nous allons donc partir sur un fork afin de répondre aux besoins exprimées par des utilisateurs, pas de souci.
Est-il possible d'avoir un coup de pouce léger pour le démarrage (première compile) ?
En contre partie nous pouvons rédiger une documentation développeur pour l'initialisation de la compilation mobile.
Voici la configuration existante :
Ce que nous avons compris (from scratch, sans documentation) :
gn_mobile_occtax contient des liens symboliques et n'écessite l'ajout des projets gn_mobile_core et gn_mobile_maps (récupération des repositories correspondant)
il persite un probleme de lien symbolique du repertoire compat : compat -> gn_mobile_core/compat non résolu, pour permettre la compilation un répertoire vide est créé dans gn_mobile_core nommé compat
NB : Android studio propose une migration vers Gradle 8.3.0 que nous avons refusé pour rester en 7.4.2 (car problème de migration détectée sur le namespace du projet)
Question 1 : Faut-il passer à la derniere version de Gradle (j'imagine que non) ?
Question 2 : la compilation amène les 2 erreurs suivantes, y a t il un étape ou un prérequis que j'aurais oublié ? Constatez vous les mêmes points avec la version 2.6.2 ? :
Erreur 1 :
Une erreur de condition ternaire (remplacée par un boolean pour valider la compilation dans un premier temps) dans le fichier gn_mobile_occtax-master/datasync/src/main/java/fr/geonature/datasync/packageinfo/io/AppPackageJsonReader.kt :
//it.packageName != null && it.packageName.isNotBlank() && it.apkUrl != null && it.apkUrl?.isNotBlank() it.packageName != null && it.packageName.isNotBlank() && it.apkUrl != null && it.apkUrl.isNotBlank()
Erreur 2 :
2024-03-04T11:38:04.659+0100 [ERROR] [system.err] public final class ObservationRecordViewModel { 2024-03-04T11:38:04.659+0100 [ERROR] [system.err] ^ 2024-03-04T11:38:04.659+0100 [ERROR] [system.err] @HiltViewModel is only supported on types that subclass androidx.lifecycle.ViewModel.
=> je ne sais pas si cela vient du mécanisme de Hilt, ou d'un autre point lié au fichier "gn_mobile_occtax-master/occtax/src/main/java/fr/geonature/occtax/features/record/presentation/ObservationRecordViewModel.kt
Question 3 : que doit contenir le répertoire "compat" ?
NB : ce projet est l'occasion également de monter en compétence sur le dev Android / Kotlin, merci pour votre indulgence :-)
Tout coup de main au démarrage est vraiment apprécié, le but est d'être autonome rapidement, et si possible de contribuer au projet via de la documentation que l'on peut apporter en fonction de notre retour d'expérience.
D'avance merci et bonne journée !