configuration maven

[Alexis.G]

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.

[Alexis.G]

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.

[ebocher]

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.

[Alexis.G]

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.

[Alexis.G]

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.