Exporter des plugins Eclipse en ligne de commande

Pour faire suite à mon article sur le déploiement de produit headless, voici un exemple illustrant comment il est également possible de n'exporter que des plugins, afin de pouvoir les mettre à jour par simple copie dans la distribution finale sans avoir à exporter tout le produit.

Export classique via IHM

L'IDE fournit nativement la possibilité d'exporter (via Ant) un ou des plugins. L'option intéressante de cet outil est la sauvegarde du script Ant appelé, qui sera utilisé plus loin en ligne de commande.

Ainsi, dans le menu File > Export se trouve l'action "Deployable plug-ins and fragments" :

Dans le panneau suivant, voici l'option à utiliser :

Le script produit ressemble à :

<project default="plugin_export" name="build">
 <target name="plugin_export">
  <pde.exportPlugins destination="C:\test" exportSource="false" 
   exportType="directory" 
   plugins="com.developpef.plugin1,com.developpef.plugin2" 
   qualifier="v20120627" useJARFormat="true"/>
 </target>
</project>

Export via ligne de commande

Pour utiliser ce script Ant en ligne de commande, voici la procédure à utiliser :

start /wait eclipse.exe -noSplash -application org.eclipse.ant.core.antRunner 
 -data ..\..\workspace -buildfile buildPatch.xml

• l'instruction "wait" permet à la console d'attendre la fin de l'exécution
• "eclipse.exe -noSplash" permet de lancer une instance du moteur d'Eclipse sans splashScreen
• le paramètre "application" indique au moteur de l'IDE de n'exécuter que le antRunner et non pas l'ouverture de l'interface
• le paramètre "data" indique le chemin vers le workspace
• le paramètre "buildfile " indique le chemin vers le fichier Ant à exécuter

Il est tout de même nécessaire de lancer Eclipse car le script Ant contient une tâche "pde.exportPlugins" qui requiert la mise en place de variables et autres scripts internes à l'IDE.

Avec ces simples éléments, il est alors possible de produire à la volée les plugins à partir d'un environnement de développement, en mode "silencieux" (sans interface).

Sources :

• http://stackoverflow.com/questions/8405771/headless-pde-build-successful-but-no-file
• http://notetodogself.blogspot.fr/2007/11/wait-in-windows-bat-script-good-way.html

Fichier(s) joint(s) :

Les bons outils pour démarrer avec Android

Comme je l'ai évoqué dans mon précédent article sur le sujet, j'ai dernièrement "essuyé les plâtres du débutant" quant à la mise en place d'un environnement de développement "optimal" pour Android.

Après avoir fait de nombreuses et vaines recherches pour essayer de trouver un retour d'expérience sur le sujet, j'ai décidé de publier le mien. Cet article étant tout à fait subjectif, je vous invite donc à critiquer, commenter, suggérer des idées sur votre expérience!

Le bon IDE

Etant un fervent adepte d'Eclipse, j'ai cependant vite été déçu par les lenteurs et pertes de performances dues aux plugins Android. Je me suis donc orienté vers IntelliJ qui supporte nativement les outils nécessaires et présente donc une fluidité d'utilisation bien meilleure.

Optimiser le déploiement

Pour tester l'application sur le terminal, il est indispensable de régulièrement re-construire le fichier APK pour le publier à nouveau. L'IDE propose cette fonctionnalité mais relance à chaque déploiement la compilation intégrale des sources, la génération des ressources (classe R.java ...) et passe généralement par l'étape de signature du fichier (ce qui implique la saisie du mot de passe etc). Pour contourner cette gêne, il est préférable de déployer à partir de ANT. En effet, les sources contiennent par défaut le fichier build.xml nécessaire. Il suffit donc d'utiliser la ligne de commande :

ant -Dsdk.dir=(pathToAndroidSDK) clean debug

La commande debug va automatiquement signer le fichier avec des paramètres par défaut pour accélérer l'opération.

Améliorer l'émulateur

L'émulateur fourni par défaut dans le SDK rempli certes très bien son devoir, mais est malheureusement très lent. Et les quelques configurations de tuning possibles n'augmentent guère les performances.

L'idéal est de s'orienter vers la mise en place d'une machine virtuelle VirtualBox exécutant le système d'exploitation Android-x86. Pour installer cet outillage, voici un très bon tutoriel sur cette page.

Pour publier le nouveau fichier APK dans la machine virtuelle, il suffit d'exécuter :

// Connexion à la VM
adb connect (IP_DE_LA_VM)
// installation
adb install -r (CHEMIN_DU_APK)

Avec cet outillage, il est possible de tester une nouvelle version de l'application en quelques secondes, là où les outils intégrés aux IDE trainent lors de la re-compilation et publication.

Les commandes utiles

En plus des commandes citées précédemment, il est assez pratique d'en garder quelques unes sous la main, parmi les plus utilisées :

• adb logcat > C:\log.txt : pour récupérer les logs distants dans un fichier local
• sqlite3 /data/data/my.package/databases/[nom_bdd] : pour accéder en ligne de commande à la base de données sqlite (sqlite3 est dans le répertoire "tools" du SDK)
• ddms : toujours dans le répertoire "tools" se trouve l'outil de debug Dalvik, très complet, contenant notamment l'explorateur de fichiers mais également beaucoup d'utilitaires :

  the Dalvik Debug Monitor Server (DDMS), which provides port-forwarding services, screen capture on the device, thread and heap information on the device, logcat, process, and radio state information, incoming call and SMS spoofing, location data spoofing, and more

Vous voilà bien armés, ne reste plus qu'à coder!

Fichier(s) joint(s) :

Piloter Camel avec Quartz et JMX

Cette fois-ci, le besoin est d'ordonnancer l'exécution d'une application Camel via le gestionnaire de tâches Quartz tout en laissant la possibilité de démarrer manuellement les routes à la demande.

Commençons par l'ordonnancement. Admettons que le programme ne doit se lancer qu'à partir de 5 heures du matin en fin de semaine. La syntaxe CRON correspondante est :

* * 5 ? * SAT-SUN

Pour configurer la route initiale avec cette règle, il faut lui spécifier une routePolicy :

@Override
public void configure() throws Exception {
  
 // Quartz
 CronScheduledRoutePolicy startPolicy = new CronScheduledRoutePolicy();
 // ne démarre que le weekend à partir de 5h du matin
 startPolicy.setRouteStartTime("* * 5 ? * SAT-SUN");
 ...
 from("file://...").routePolicy(startPolicy).noAutoStartup().routeId("firstRoute")...
}

Ainsi donc, la route n'est pas démarrée au lancement du contexte mais délègue cette tâche à l'ordonnanceur. (Ne pas oublier d'ajouter la dépendance camel-quartz)

Passons à la mise en place de JMX pour piloter à distance Camel.

Au démarrage de l'application, il faut référencer un bean particulier ayant connaissance du contexte Camel auprès du server JMX de la JVM :

MBeanServer server = ManagementFactory.getPlatformMBeanServer();
MyAgentManagerMXBean mbean = new MyCamelMBean(camelContext);
ObjectName name = new ObjectName("my.jmx.domain.MyDomain:type=MyCamelMBean,name=myCamelMBean");
server.registerMBean(mbean, name);

La paramètre camelContext du bean est une instance du context Camel, par exemple de org.apache.camel.main.Main. Je précise au passage qu'afin de rendre disponible l'interface à JMX, le nom de celle-ci doit être suffixé par MXBean (il s'agit d'une convention JMX). Et voici comment sont écrites l'interface et l'instance du bean mbean

public interface MyAgentManagerMXBean {
 
 /**
  * Start Camel manually, overriding quartz schedule
  * @throws Exception
  */
 public void camelManualStart() throws Exception;

}

public class MyCamelMBean implements MyAgentManagerMXBean {

 private Main camel;
 
 public MyCamelMBean(Main context) {
  camel = context;
 }

 @Override
 public void camelManualStart() throws Exception {
  camel.getRouteBuilders().get(0).getContext().startRoute("firstRoute");
 }
}

Avec cette configuration, il est alors possible, avec n'importe quelle console JMX (ici la JConsole) de démarrer manuellement la route configurée avec Quartz :

J'en profite pour ajouter un exemple permettant de récupérer des informations directement de Camel, par exemple ici le nombre de message traités sur une route :

public long getSourceFilesManagedNb() {
 long result = 0;
 try {
  JMXServiceURL url = new JMXServiceURL("service:jmx:rmi:///jndi/rmi://localhost:1616/jmxrmi");
  JMXConnector jmxc = JMXConnectorFactory.connect(url);
  MBeanServerConnection server = jmxc.getMBeanServerConnection();
  ObjectName objName = new ObjectName("org.apache.camel:type=routes,name=\"firstRoute\",*");
  List<ObjectName> cacheList = new LinkedList<ObjectName>(server.queryNames(objName, null));
  for (ObjectName objName2 : cacheList) {
   result = (Long) server.invoke(objName2, "getExchangesCompleted", null, null);
  }
 } catch (Exception e) {
  e.printStackTrace();
 }
 return result;
}

Voilà tout!

Fichier(s) joint(s) :

Comment je me suis lancé dans le développement mobile

J'ai décidé d'expliquer dans cet article comment, après quelques semaines de recherches, je me suis lancé dans le développement d'une application pour appareils mobiles. Comme le processus de décision a été plutôt long et le fruit de nombreux questionnements, je le rend public afin d'aider ceux qui seraient dans la même perspective à prendre une bonne décision.

Le contexte du projet

L'idée originelle était de développer un petit "assistant" dans la pratique d'une activité de loisir. Etant moi-même pratiquant, je me suis rendu à l'évidence qu'il fallait que l'outil soit toujours à portée de main de l'utilisateur, donc sur un appareil mobile! (je garde pour le moment le mystère que le sujet exact du projet :-) )

Le choix de la technologie

Il existe aujourd'hui pas mal de moyens pour réaliser une application nomade. Ayant une bonne expérience de Java, j'ai d'abord essayé de créer une simple application Swing emballée dans un Jar, puisque la majorité des terminaux savent lire ce genre de paquet. Mais là premier écueil : les Manifest des applications Java sont en réalité totalement différents de ceux des applications mobiles... Qu'à cela ne tienne, utilisons J2ME... Dès la première tentative de compilation du projet, c'est le drame : J2ME requiert un compilateur compatible 1.3, donc adieu Swing, adieu encore les listes paramétrées et pire, adieu les listes tout court, à remplacer par des Vecteurs. C'en est trop, il faut trouver autre chose!

Les premières recherches sur le net concernant le développement mobile et la compatibilité inter-plateformes font apparaître qu'il est nécessaire d'utiliser HTML5, CSS3 et Javascript... Je n'ai jamais été très fan du développement web... Mais cela pourrait faire une bonne raison de s'y mettre! En regardant de plus près, il existe déjà pas mal de solutions "in cloud" pour déployer un projet web sur toutes les plateformes mobiles. Super! Maintenant, il faut encore rattraper le retard accumulé auprès des technos citées précédemment pour mettre en place quelque chose de correct. Au fond je ne suis pas très motivé pour ça.

Une solution pour faire le pont Java-Web? GWT, me souffle-t-on! Bon sang mais c'est bien sûr! Superbe occasion de se lancer! Et là, pour faire court : la présentation sur le site officiel est alléchante quoique plutôt sommaire, conceptuellement cela semble complexe mais bien organisé mais alors pour la réalisation... Ils ont sorti l'artillerie lourde! A grand renfort de lignes de commandes, panels graphiques et objets ésotériques, on est vite perdus!

Donc c'est le moment de se décider pour un développement spécifique à une plateforme. Restreignons le choix aux plus répandues : iOS et Android. N'ayant jamais fait de C, il ne reste plus qu'Android (qui semble prendre de plus en plus de parts de marché, donc intéressant). Et là, enfin, le Graal! Un site officiel qui présente plus clairement ce que permet le SDK, une documentation qui semble plus accessible et plus claire et surtout du code basé uniquement sur JAVA, du XML maison et seulement quatre ou cinq grands concepts techniques et/ou généraux sur le fonctionnement d'une appli... Ouf! De plus, ayant une vieillissante expérience en Flex, tout se ressemble.

Les débuts

Alors c'est parti, je me lance! Etant habitué à Eclipse, je récupère le SDK Android et la batterie de plugins nécessaire, je génère le premier projet "Hello world" et après la configuration de l'émulateur c'est la désillusion : ça rame! Eclipse est connu pour vite monter en charge lors de lourdes opérations, mais le mode Debug sur l'émulateur Android bat des records, mon PC est submergé, difficile d'avancer.

En se renseignant un peu, on comprend vite qu'il est préférable d'utiliser l'émulateur de manière indépendante de l'IDE, en ligne de commande (simple). Faisons ça. Reste l'IDE lui même qui malgré tout semble peiné par la surcharge des plugins Android. Il faudra donc lui faire des infidélités cette fois-ci : je me tourne vers IntelliJ IDEA. Et là effectivement, on respire un peu! D'autant plus que le développement Android semble grandement amélioré par une intégration à l'IDE beaucoup plus importante : auto-complétion des informations textuelles par lien direct avec les fichiers de ressources XML, meilleure organisation du projet par reconnaissance des éléments spécifiques à l'architecture Android (dossier "res") etc.

Enfin cette fois, c'est parti! C'est assez plaisant (pour un débutant) de voir une appli fonctionner sur un appareil mobile. Je profiterai dans l'avenir de cette nouvelle expérience pour publier quelques articles sur le développement Android.

A suivre donc...

Fichier(s) joint(s) :

Eclipse : réutiliser les icônes JDT

Aujourd'hui un petit pense-bête, pour faire suite à mon vieil article sur les icônes Eclipse, voici le lien vers la page contenant tous les icônes utilisés par JDT : Help Eclipse. Et vive RCP

Fichier(s) joint(s) :