Bonjour tout le monde !
Je suis en train d'essayer de configurer netbeans pour travailler sur OrbisGIS, en espérantéviter ainsi lse galères qu'Eclipse m'impose chaque jour... Et je pense avoir trouvé un problème dans la conf maven du module orbisgis-core . Je m'explique. dans le module en question, on voit des imports relatifs au module common (tout ce qui est org.orbisgis.utils). Mais ce module n'est pas déclaré comme dépendance à orbisgis-core. la solution la plus évidente (et qui marche chez moi, même s'il y a peut être mieux) : dans la section <dependencies>, rajouter une sous-section : <dependency> <groupId>org.orbisgis</groupId> <artifactId>commons</artifactId> <version>1.1.0</version> </dependency> Il est possible que le problème ne soit pas résolu directement. j'ai aussi fait un mvn install sur le module commons. de même, on a besoin d'une section <dependency> <groupId>org.grap</groupId> <artifactId>grap</artifactId> <version>1.4.0</version> </dependency> dans le même pom.xml (celu de orbisgis-core, donc) Voilà voilà :-) @+ Alexis. |
Toujours dans ce même pom.xml (tant que j'y suis... ^_^ )
On a un appel non résolu à imageJ dans le coeur. Il n'y a effectivement de référence au package ij ni dans le pom de ce module, ni dans le pom du parent. Donc je corrige ça en ajoutant (pour changer) : <dependency> <groupId>ij</groupId> <artifactId>imagej</artifactId> <version>1.39p</version> </dependency> Ce fix (comme celui pour grap) est destiné disparaître... mais malgré tout, en attendant, je pense que c'est pas mal :-) Cordialement, Agemen. -- OrbisGIS supporter. |
Administrator
|
Hello,
Normalement la déclaration des modules dans le pom parent devrait être suffisante. Mais bon il est vrai que netbeans c'est une autre histoire ;-). Erwan. |
en fait j'avais un problème aussi vec eclipse, je pensais justement
que cette déclaration n'était pas suffisante. J'étais obligé de rajouter des imports de projet dans eclipse (j'ai fait un projet avec un pom parent, un peu comme OrbisGIS, pour mettre en lumière les choses à faire.). De ce que j'ai compris de la doc maven (que je n'ai pas sous les yeux, je retrouverai ça plus tard ^_^ ) les choses se passent de la façon suivante : Dans le module parent, on déclare les fils et les dépendances communes à tous les fils. Ça permet de simplifier les déclarations de dépendance, et de simplifier la gestion des changements de version. Les fils n'ont pas besoin d'être ordonné dans le pom parent. Maven se charge de résoudre les dépendances entre les fils **en fonction des dépendances déclarées dans lesdits fils**. Autrement dit, au niveau du pom père, on ne s'inquiète pas de l'ordre de résolution. Par contre, dans les fils, on doit toujours déclarer les dépendances (pour qu'elles soient résolues), en faisant attention de conserver un graphe orienté sans boucle (ou même un arbre, je maîtrise pas toutes les subtilités de l'héritage dans maven ^_^ ) Si je tente de compiler les sources du trunk from scratch (sans eclipse), j'ai des erreurs. Je ne compile pas le module parent mais un fils (en l'occurence orbisgis-core, qui dépend de grap. grap n'est pas déclaré dans le pom.xml de orbisgis-core, et ne peut l'être dans le pom parent). Il est possible que ça passe quand on compile le module parent... Je ne peux pas vérifier, j'ai un Build failure ^_^ . si ça passe (je pars du principe que c'est le cas ^_^), c'est surement du à l'ordre bien choisi de la déclaration des modules dans le parent. sauf que ça devrait être à maven de déterminer l'ordre, je pense. Et que ça nous empêche de compiler certains modules indépendamment de l'ensemble du logiciel. Et je trouve ça assez embêtant ^_^ Je retrouve la doc d'où je tiens ça, je reviens par ici ;-) Bonne soirée, Alexis. -- OrbisGIS supporter. |
In reply to this post by ebocher
Du coup, je me suis replongéé dans la doc de Maven. Pour les lecteurs
qui ne connaissent pas trop ce logiciel de configuration par convention, je conseille deux bouquins accessibles gratuitement en ligne (sous une licence Creative Commons) chez sonatype : Maven : The definitive guide (ou Maven : The complete reference, selon que vous allez le chercher chez O'Reilly, donc en librairie, ou chez sonatype) : http://www.sonatype.com/books/mvnref-book/reference/public-book.html Maven by example : http://www.sonatype.com/books/mvnex-book/reference/multimodule-sect-building-multimodule.html ce deuxième lien pointe directement le chapitre qui m'intéresse : "The Reactor preserves the order of modules as defined in the POM unless changes need to be made. A helpful mental model for this is to picture that modules with dependencies on sibling projects are "pushed down" the list until the dependency ordering is satisfied." dans notre cas, si on regarde le pom de platform, effectivement, les dépendances sont bien "satisfaites" manuellement. Les modules sont appelés à la compilation dans un ordre correct. Mais ça devrait être à Maven de résoudre cet ordre. |
Free forum by Nabble | Edit this page |