Quand j'ai besoin d'essayer une lib sans impacter du code existant, je crée rapidement un projet jetable avec mvn :
mvn archetype:generate
Le projet par défaut, quickstart, convient : j'appuie directement sur return. Quelques questions génèrent un pom.xml auquel j'ajoute la librairie à expérimenter (mvnrepository.com fournit groupId et artifactId) :
org.easytesting
fest-assert
1.3
Puis je génère le .classpath d'eclipse avec
mvn eclipse:eclipse
Toutes les dépendances sont téléchargées au passage. C'est un cas où les dépendances transitives aident, alors que sur du code de production cette transitivité nous a causé des soucis. Il ne reste qu'à importer le projet dans eclipse (Alt-f i "Existing Projects into Workspace").
Quand j'ai envie de rentrer dans le code source des lib, je régénère le .classpath avec -DdownloadSources=true
:
mvn eclipse:clean eclipse:eclipse -DdownloadSources=true
Les sources sont récupérées et le .classpath se voit enrichit du sourcepath
de chaque dépendance :
Attention à ne pas oublier eclipse:clean
sinon le .classpath n'est pas enrichit.
Et buildr ?
Buildr permet de réaliser une partie de ces opérations, moyennant la création d'une arborescence minimale à la norme maven :
mkdir -p src/main/java src/test/java
- créer une première classe
buildr
propose ensuite de générer un buildfile à partir de cette arborescence :To use Buildr you need a buildfile. Do you want me to create one?: 1. From directory structure
Répondre
1
amène à :define "creerRapidementUnProjet" do ... compile.with # Add classpath dependencies test.compile.with # Add classpath dependencies ... end
Sur cette première partie, buildr est beaucoup plus rapide que maven, mais il faut ensuite ajouter les dépendances une par une. Même si mvnrepository.com donne le format buildr, la recherche de chaque dépendance est vite rédhibitoire.</li>
- pour finir,
buildr eclipse
génère le .classpath
</ol>
Update: le titre renforce l'aspect sources suite au commentaire de Bruno (remplace Essayer une lib dans un projet jetable).