Le Montpellier JUG: C’est parti!


J’en ai parlé quelques fois sur ce blog (ici ou ), le Java User Group Montpelliérain est maintenant prêt pour sa première soirée planifiée pour le 13 avril 2011. Au programme, on commence l’aventure avec les sujets GWT et Maven 3 présentés par des experts locaux.

Pour plus d’informations et pour les inscriptions à cette première soirée, ca se passe sur le site tout beau tout neuf développé pour l’occasion (je reviendrais sur ce qui à été utilisé plus tard) : http://www.jug-montpellier.org/. N’hésitez pas à venir jeter un coup d’oeil, dire bonjour, vous instruire et boire un coup!

Maven2 : Deployer ses artefacts sur un repo alternatif en FTP ‘a la mano’


Le besoin du jour : « J’ai des artefacts packagés avec Maven2 et je dois les partager avec des partenaires sans passer par un déploiement standard de mon projet mais en passant par un serveur FTP ». En plus, en terme de contrainte majeure, je ne veux absolument pas modifier mes bon vieux POMs…

Bon, comme je le dis souvent « Google est ton ami », mais aujourd’hui Google ne l’est pas (comme le temps dehors, de la neige en Mars a Montpellier, mais ou va-t-on?). Bref, faisons le bêtement :


mvn deploy -DaltDeploymentRepository=chamerling.maven.snapshot::default::ftp://ftpperso.free.fr/maven/repository/snapshot

Je viens de dire a Maven2 de déployer mon artefact sur un repository dont l’ID est chamerling.maven.snapshot (pour rappel, cela veut dire que Maven2 va aller chercher dans mon settings.xml un serveur dont l’ID est chamerling.maven.snapshot pour récupérer le login et le mot de passe) en FTP sur l’URL ftp://ftpperso.free.fr/maven/repository/snapshot. Et c’est la que mon autre ami Maven2 (bon OK je n’ai que des amis virtuels…) me dit :


[INFO] Error retrieving previous build number for artifact 'foo:bar:pom': repository metadata for: 'snapshot foo:bar:1-SNAPSHOT' could not be retrieved from repository: chamerling.maven.snapshot due to an error: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp
Component descriptor cannot be found in the component repository: org.apache.maven.wagon.Wagonftp.

Ok bon c’est normal… Wagon est la librairie de transport abstraite utilisée par Maven2 et par défaut FTP n’est pas supporté. D’ailleurs sur le site du plugin deploy de Maven2 on remarque bien qu’il faut normalement définir dans le POM que l’on veut utiliser l’extension FTP de Wagon :


<build>
<extensions>
<!-- Enabling the use of FTP -->
<extension>
<groupId>org.apache.maven.wagon</groupId>
<artifactId>wagon-ftp</artifactId>
<version>1.0-beta-6</version>
</extension>
</extensions>
</build>

Oui mais moi je ne veux pas modifier mon POM! L’astuce c’est de rajouter l’extension FTP-Wagon dans le classpath de Maven2 ie ajouter la librairie Wagon FTP dans M2_HOME/lib et la ‘Oh Miracle’, ca ne marche pas…


[INFO] ------------------------------------------------------------------------
[ERROR] BUILD ERROR
[INFO] ------------------------------------------------------------------------

[INFO] Error retrieving previous build number for artifact 'foo:bar:pom': repository metadata for: 'snapshot foo:bar:1-SNAPSHOT' could not be retrieved from repository: chamerling.maven.snapshot due to an error: Unsupported Protocol: 'ftp': Cannot find wagon which supports the requested protocol: ftp
org.apache.commons.net.ProtocolCommandListener
[INFO] ------------------------------------------------------------------------

Normal, Wagon FTP utilise commons-net pour tout ce qui est communication, j’ajoute donc le JAR de commons-net  2.0 dans mon M2_HOME/lib et là ça marche beaucoup mieux :


[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESSFUL
[INFO] ------------------------------------------------------------------------

Outils Petals ESB : Librarie pour binder des services Web


Dans un précédent article, je décrivais comment ‘proxifier’ un Web service dans Petals ESB avec un plugin Maven maison. Ce plugin Maven utilise une librairie Java que j’ai développé pour lier et exposer des Web services dans/avec Petals ESB.

Le ‘problème’ actuel de Petals ESB est qu’il est pleinement basé sur la spécification JBI, cela veut dire que actuellement, si on veut exposer un service JBI en tant que Web service, il faut créer un fichier de configuration (le fameux JBI.xml), le packager dans une unité de service (Service Unit – SU), et packager cette SU dans un assemblage de services (Service Assembly – SA). Bien sur des outils comme le Petals Studio sont la pour aider les développeurs à intégrer leurs services, moi je me place plus dans la peau du ‘Core Developper’ et je pour le moment je n’ai pas eu l’utilité d’outils graphiques pour configurer Petals.

Dans une de mes taches actuelles, je suis en train d’étendre Petals pour le faire communiquer sur Internet et je développe ce que j’appelle l’API de Monitoring & Management (M&M API) qui est exposée (pour le moment seulement) en Web service. La partie Management de l’API doit permettre à un administrateur de la plateforme, de ‘binder’ des services (Web, REST, …) sans se soucier de la partie JBI.
L’API fournit donc une opération du style bind(URI wsdl). Coté serveur, j’utilise :

  1. Une librairie maison de génération de SA
  2. Je déploie localement cette SA pour ‘binder’ un Web service au bus.
  3. J’expose ce service de management avec la feature expliquée dans ce post

Un exemple d’utilisation de la librairie est donné dans le listing suivant (binder au bus, le Service Web Version de Axis2) :


package org.ow2.petals.tools.generator.jbi;

import java.io.File;
import java.net.URI;
import java.net.URISyntaxException;
import java.util.HashMap;
import java.util.Map;
import org.ow2.petals.tools.generator.jbi.api.JBIGenerationException;
import org.ow2.petals.tools.generator.jbi.ws2jbi.WS2Jbi;

public class BindAxis2Version {

public static void main(String[] args) throws JBIGenerationException, URISyntaxException {

String wsdl = "http://localhost:8080/axis2/services/Version?wsdl";
Map<String, String> map = new HashMap<String, String>();

// let's say that we want to generate SA for SOAP component 4.0
map.put(org.ow2.petals.tools.generator.commons.Constants.COMPONENT_VERSION, "4.0");

URI wsdlURI = new URI(wsdl);

File f = new WS2Jbi(wsdlURI, map).generate();

System.out.println("Service Assembly is available at " + f.getAbsolutePath());

}
}

Pour utiliser WS2Jbi, utilisez dans votre projet Maven, la dépendance :


<dependency>

<groupId>org.ow2.petals.sandbox</groupId>

<artifactId>petals-ws2jbi</artifactId>

<version>1.0-SNAPSHOT</version>

</dependency>

Celle ci est normalement disponible est mise a jour régulièrement sur le repository Maven d’OW2 http://maven.ow2.org/maven2-snapshot/. Les sources sont disponibles dans ma Sandbox Petals.

Maven est ton ami #2 : Effective POM


Après « Maven est ton ami #1 : Dependency tree« , le court article du jour est juste une note pour les personnes qui se (et me) demandent souvent pourquoi ils n’arrivent pas a releaser (entre autres)…
Ce qui est bien avec Maven2, c’est que l’on peut ‘overrider’, utiliser des parents, définir ses mots de passe sans les publier publiquement… Mais ce qui est moins bien, quand on ne maitrise pas Maven, c’est que l’on se perd vite dans toutes ses configurations (ajoutez par dessus un proxy, de l’authentification, des repositories privés…). Est c’est la que l’on se demande comment on peut s’y retrouver…

Heureusement, les gens de chez Maven2 ne sont pas si bêtes, le plugin Help permet de lister le POM effectif du projet courant en lancant la commande

# mvn help:effective-pom

Simple et efficace. Les gens qui se demandent, par exemple, pourquoi ils ne sont pas bien authentifiés lors d’une release peuvent alors verifier dans le POM généré, que leurs login/password ne sont pas définis pour le bon ID de serveur…

Using Nexus as Proxy for corporate Open Source project


The problem when working on an Open Source project which is hosted on a consortium (OW2 in our case) is that the users and developers community which are not working in the same organization than you must be able to compile your project without the help of your Maven2 proxy…

The current article will focus on how to use Sonatype Nexus on the corporate side and how to deliver your independant Open Source project. I will not speak about how to use Nexus as artifact repository here (will probably come in another post).

1. Always define repositories in your project POMs
This is because the community must be able to compile all without any proxy. It is quite important to give IDs to each repository and to keep the ID list in mind…
For example, here is the OW2 Release repository definition :

		<repository>
			<id>ow2.release</id>
			<name>OW2 Repo</name>
			<url>http://maven.ow2.org/maven2</url>
			<snapshots>
				<enabled>false</enabled>
			</snapshots>
			<releases>
				<enabled>true</enabled>
			</releases>
		</repository>

2. Give the list of repositories to proxify
2.1 Add the repository to Nexus
Ask your Nexus administrator to add the repositories you want to proxify to Nexus (this is not part of this blog entry, refer to the Nexus guide which is quite complete for that).

2.2 Define the list in your local settings.xml file
In the settings.xml file located under $HOME/.m2/, you must define the list of repository IDs you want to be handled by your Nexus Proxy:

<mirror>
<id>nexus</id>
<name>Nexus Mirror</name>
<url>http://m2proxy:8081/nexus/content/groups/public/</url>
<mirrorOf>central,ow2.release,ow2-plugin.release,ow2-plugin</mirrorOf>
</mirror>

This configuration will say to the Maven engine that all the calls to the 4 repositories (‘central,ow2.release,ow2-plugin.release,ow2-plugin’) will be forwarded to the corporate Nexus proxy running on http://m2proxy:8081.

Following this procedure, you will be able to compile your project with AND without the proxy but the proxy will really optimize your compilation time.