Compiler un Module Maven avec une Copie de Dépôt Local

Cet article concerne Maven 3. Imaginons le cas où l’on vous fournit les sources d’un module Maven à compiler, avec une copie d’un dépôt local. C’est un cas que l’on rencontre parfois quand on fait du support.

La première chose est de mettre à jour votre fichier ~/.m2/settings.xml pour indiquer l’emplacement de votre nouveau dépôt local (celui que l’on vous aura fourni).

<settings xmlns="http://maven.apache.org/SETTINGS/1.0.0"
      xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
      xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0
                          https://maven.apache.org/xsd/settings-1.0.0.xsd">

      <localRepository>/home/vzurczak/Bureau/bug_jaspersoft/repository</localRepository>
</settings>

Ensuite, si vous tentez de compiler votre projet en l’état, vous risquez de rencontrer une erreur. Dans notre cas, c’était du genre…

Non-resolvable parent POM for…

… alors que le projet en question était bien dans le dépôt fourni.
Même avec l’option -o (pour offline / hors-ligne), cette erreur continuait d’apparaître. Finalement, il a fallu utiliser l’option -llr.

Exemple : mvn clean install -llr

Ainsi, le dépôt local est utilisé.
Cette option est une abréviation pour –legacy-local-repository. La documentation précise…

Use Maven 2 Legacy Local Repository behaviour, ie no use of _remote.repositories. Can also be activated by using -Dmaven.legacyLocalRepo=true

Publicités

Petals Studio s’appuie maintenant sur Maven et Tycho

Depuis ses débuts, le projet Petals Studio souffrait d’une grosse lacune (enfin, une parmi d’autres) : les builds n’étaient pas scriptés. J’appréhendais beaucoup cette étape, dans la mesure où j’avais pu observer dans le projet Eclipse STP toutes les difficultés qu’une telle entreprise pouvait représenter. Les builds de STP s’appuyaient sur un projet qui s’appelle Buckminster et auquel j’ai pu me frotter un peu avant d’aller voir ailleurs. Il s’avère qu’en ce moment, la solution qui a la cote, c’est Tycho.

Tycho, c’est un plug-in Maven qui permet de compiler des bundles OSGi mais aussi tous les artéfacts Eclipse.
Le projet a récemment déménagé chez la Fondation Eclipse. Et même s’il est toujours en incubation, ça marche bien et il y a une vraie communauté, côté utilisateur et développeur. Sans oublier qu’il y a de nombreux exemples disponibles.

J’avais posté un billet il y a quelques temps sur la mise en place de Tycho pour le projet SCA Tools.
La suite logique, en ce qui me concerne, était donc de le mettre en place pour le studio. Et c’est donc chose faite, depuis quelques heures. Il a fallu revoir un peu la hiérarchie du SVN, mais rien de radical. Le plus embêtant, c’est qu’il a fallu externaliser le product Eclipse dans un projet bien à lui, et définir une plateforme cible dans un autre projet. La conséquence directe, c’est que je ne peux exporter ce product qu’avec Tycho. Pour un export avec l’outillage Eclipse (PDE), je suis obligé de passer par l’ancien product, que j’ai conservé.

Quelque part, on a donc 2 versions de Petals Studio qui co-existent.
Et je ne peux malheureusement pas tout miser sur Tycho pour le moment, puisqu’il manque encore 2-3 fonctionnalités. Ce sont plutôt des questions de forme. J’ai réglé tous les problèmes de configuration, warnings et autres logs malfaisants. Le studio généré fonctionne. Mais il y a quelques fichiers en trop à la racine et surtout, j’ai dû mal à gérer le branding, c’est à dire la personnalisation du RCP. J’ai listé ce qui reste à faire sur le JIRA de la société.

Ce n’est qu’une question de temps avant que cela ne soit réglé.
En attendant, je ne sais pas quelle solution d’export sera utilisée pour la prochaine release de Petals Studio. Celle-ci aura lieu dans le courant du mois de juin. Depuis le temps qu’on en parlait, officieusement du moins…