Dans ce billet, je vais montrer comment l’installer.

Un petit détail avant de commencer : Subversive est divisé en deux modules (grossomodo) :

• SVN Team Provider : intégration dans Eclipse
• SVN Connector : manipulation du repository SVN

Le premier module est un projet interne Eclipse, mais la seconde partie ne l’est pas.
Il faut donc ajouter les deux update-site suivants dans p2 (nouveau gestionnaire de plugins d’Eclipse) :

=> http://download.eclipse.org/technology/subversive/0.7/update-site/
=> http://www.polarion.org/projects/subversive/download/eclipse/2.0/ganymede-site/
=> http://community.polarion.com/projects/subversive/download/eclipse/2.0/update-site/

Dans Eclipse, cliquez sur le menu [ Help > Software Updates ].
Dans la fenêtre qui s’affiche, activez l’onglet « Available Software » et cliquez sur le bouton « Add Site » pour ajouter l’update-site des connecteurs SVN.

Validez.
Toujours dans l’onglet « Available Software« , saisissez « svn » dans la zone de recherche et sélectionnez :

• SVN Team Provider
• SVN Kit (ou autre implémentation)

Cliquez enfin sur « Install« .

Après redémarrage d’Eclipse, Subversive devrait être fonctionnel.

Par défaut, Jetty utilise le port 8080, ce qui peut poser problème quand on a un autre serveur sur ce port.

Pour résoudre celà, on va créer un fragment qui contient les fichiers de configuration de Jetty. J’avais présenté en détail comment céer un fragment dans le billet précédent : « Préparation de l’environnement : configuration de log4j »

Créez donc un fragment en utilisant l’assistant offert par PDE en utilisant « sse.jetty.config » comme nom et en sélectionnant « org.springframework.osgi.jetty.start.osgi » comme host.

Dans ce fragment, créez un dossier « etc » à la racine du projet avec un fichier jetty.xml dedans dont voici le contenu :

<?xml version="1.0"?> 

<!DOCTYPE Configure PUBLIC "-//Mort Bay Consulting//DTD Configure//EN" "http://jetty.mortbay.org/configure.dtd"> 

 

<!-- =============================================================== --> 

<!-- Configure the Jetty Server  (OSGi specific)                     --> 

<!--                                                                 --> 

<!-- Documentation of this file format can be found at:              --> 

<!-- http://docs.codehaus.org/display/JETTY/jetty.xml                --> 

<!--                                                                 --> 

<!-- =============================================================== --> 

 

 

<Configure id="Server" class="org.mortbay.jetty.Server"> 

 

    <!-- =========================================================== --> 

    <!-- Server Thread Pool                                          --> 

    <!-- =========================================================== --> 

    <Set name="ThreadPool"> 

      <!-- Default bounded blocking threadpool  

      --> 

      <New class="org.mortbay.thread.BoundedThreadPool"> 

        <Set name="minThreads">10</Set> 

        <Set name="maxThreads">250</Set> 

        <Set name="lowThreads">25</Set> 

      </New> 

 

      <!-- Optional Java 5 bounded threadpool with job queue  

      <New class="org.mortbay.thread.concurrent.ThreadPool"> 

        <Set name="corePoolSize">250</Set> 

        <Set name="maximumPoolSize">250</Set> 

      </New> 

      --> 

    </Set> 

 

 

 

    <!-- =========================================================== --> 

    <!-- Set connectors                                              --> 

    <!-- =========================================================== --> 

    <!-- One of each type!                                           --> 

    <!-- =========================================================== --> 

 

    <!-- Use this connector for many frequently idle connections 

         and for threadless continuations. 

    -->     

    <Call name="addConnector"> 

      <Arg> 

          <New class="org.mortbay.jetty.nio.SelectChannelConnector"> 

            <Set name="host"><SystemProperty name="jetty.host" /></Set> 

            <Set name="port"><SystemProperty name="jetty.port" default="9090"/></Set> 

            <Set name="maxIdleTime">30000</Set> 

            <Set name="Acceptors">2</Set> 

            <Set name="statsOn">false</Set> 

            <Set name="confidentialPort">9443</Set> 

      <Set name="lowResourcesConnections">5000</Set> 

      <Set name="lowResourcesMaxIdleTime">5000</Set> 

          </New> 

      </Arg> 

    </Call> 

 

    <!-- Use this connector if NIO is not available.  

    <Call name="addConnector"> 

      <Arg> 

          <New class="org.mortbay.jetty.bio.SocketConnector"> 

            <Set name="port">8081</Set> 

            <Set name="maxIdleTime">50000</Set> 

            <Set name="lowResourceMaxIdleTime">1500</Set> 

          </New> 

      </Arg> 

    </Call> 

    --> 

 

    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> 

    <!-- To add a HTTPS SSL listener                                     --> 

    <!-- see jetty-ssl.xml to add an ssl connector. use                  --> 

    <!-- java -jar start.jar etc/jetty.xml etc/jetty-ssl.xml             --> 

    <!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - --> 

     

    <!-- =========================================================== --> 

    <!-- Set up global session ID manager                            --> 

    <!-- =========================================================== --> 

    <!-- 

    <Set name="sessionIdManager"> 

      <New class="org.mortbay.jetty.servlet.HashSessionIdManager"> 

        <Set name="workerName">node1</Set> 

      </New> 

    </Set> 

    --> 

 

    <!-- =========================================================== --> 

    <!-- Set handler Collection Structure                            -->  

    <!-- =========================================================== --> 

    <Set name="handler"> 

      <New id="Handlers" class="org.mortbay.jetty.handler.HandlerCollection"> 

        <Set name="handlers"> 

         <Array type="org.mortbay.jetty.Handler"> 

           <Item> 

             <New id="Contexts" class="org.mortbay.jetty.handler.ContextHandlerCollection"/> 

           </Item> 

           <Item> 

             <New id="DefaultHandler" class="org.mortbay.jetty.handler.DefaultHandler"/> 

           </Item> 

           <Item> 

             <New id="RequestLog" class="org.mortbay.jetty.handler.RequestLogHandler"/> 

           </Item> 

         </Array> 

        </Set> 

      </New> 

    </Set> 

     

    <!-- =========================================================== --> 

    <!-- Configure the context deployer                              --> 

    <!-- A context deployer will deploy contexts described in        --> 

    <!-- configuration files discovered in a directory.              --> 

    <!-- The configuration directory can be scanned for hot          --> 

    <!-- deployments at the configured scanInterval.                 --> 

    <!--                                                             --> 

    <!-- This deployer is configured to deploy contexts configured   --> 

    <!-- in the $JETTY_HOME/contexts directory                       --> 

    <!--                                                             --> 

    <!-- =========================================================== --> 

     

    <!-- 

  <Call name="addLifeCycle"> 

      <Arg> 

        <New class="org.mortbay.jetty.deployer.ContextDeployer"> 

          <Set name="contexts"><Ref id="Contexts"/></Set> 

          <Set name="configurationDir"><SystemProperty name="jetty.home" default="."/>/contexts</Set> 

          <Set name="scanInterval">1</Set> 

        </New> 

      </Arg> 

    </Call> 

  --> 

    <!-- =========================================================== --> 

    <!-- Configure the webapp deployer.                              --> 

    <!-- A webapp  deployer will deploy standard webapps discovered  --> 

    <!-- in a directory at startup, without the need for additional  --> 

    <!-- configuration files.    It does not support hot deploy or   --> 

    <!-- non standard contexts (see ContextDeployer above).          --> 

    <!--                                                             --> 

    <!-- This deployer is configured to deploy webapps from the      --> 

    <!-- $JETTY_HOME/webapps directory                               --> 

    <!--                                                             --> 

    <!-- Normally only one type of deployer need be used.            --> 

    <!--                                                             --> 

    <!-- =========================================================== --> 

    <!-- 

    <Call name="addLifeCycle"> 

      <Arg> 

        <New class="org.mortbay.jetty.deployer.WebAppDeployer"> 

          <Set name="contexts"><Ref id="Contexts"/></Set> 

          <Set name="webAppDir"><SystemProperty name="jetty.home" default="."/>/webapps</Set> 

    <Set name="parentLoaderPriority">false</Set> 

    <Set name="extract">true</Set> 

    <Set name="allowDuplicates">false</Set> 

          <Set name="defaultsDescriptor"><SystemProperty name="jetty.home" default="."/>/etc/webdefault.xml</Set> 

        </New> 

      </Arg> 

    </Call> 

    --> 

 

    <!-- =========================================================== --> 

    <!-- Configure Authentication Realms                             --> 

    <!-- Realms may be configured for the entire server here, or     --> 

    <!-- they can be configured for a specific web app in a context  --> 

    <!-- configuration (see $(jetty.home)/contexts/test.xml for an   --> 

    <!-- example).                                                   --> 

    <!-- =========================================================== --> 

    <!-- 

    <Set name="UserRealms"> 

      <Array type="org.mortbay.jetty.security.UserRealm"> 

        <Item> 

          <New class="org.mortbay.jetty.security.HashUserRealm"> 

            <Set name="name">Test Realm</Set> 

            <Set name="config"><SystemProperty name="jetty.home" default="."/>/etc/realm.properties</Set> 

            <Set name="refreshInterval">0</Set> 

          </New> 

        </Item> 

      </Array> 

    </Set> 

    --> 

 

    <!-- =========================================================== --> 

    <!-- Configure Request Log                                       --> 

    <!-- Request logs  may be configured for the entire server here, --> 

    <!-- or they can be configured for a specific web app in a       --> 

    <!-- contexts configuration (see $(jetty.home)/contexts/test.xml --> 

    <!-- for an example).                                            --> 

    <!-- =========================================================== --> 

    <Ref id="RequestLog"> 

      <Set name="requestLog"> 

        <New id="RequestLogImpl" class="org.mortbay.jetty.NCSARequestLog"> 

          <Set name="filename"><SystemProperty name="jetty.logs" default="./logs"/>/yyyy_mm_dd.request.log</Set> 

          <Set name="filenameDateFormat">yyyy_MM_dd</Set> 

          <Set name="retainDays">90</Set> 

          <Set name="append">true</Set> 

          <Set name="extended">true</Set> 

          <Set name="logCookies">false</Set> 

          <Set name="LogTimeZone">GMT</Set> 

        </New> 

      </Set> 

    </Ref> 

     

    <New id="ServerLog" class="java.io.PrintStream"> 

      <Arg> 

        <New class="org.mortbay.util.RolloverFileOutputStream"> 

          <Arg><SystemProperty name="jetty.logs" default="./logs"/>/yyyy_mm_dd.stderrout.log</Arg> 

          <Arg type="boolean">false</Arg> 

          <Arg type="int">90</Arg> 

          <Arg><Call class="java.util.TimeZone" name="getTimeZone"><Arg>GMT</Arg></Call></Arg> 

          <Get id="ServerLogName" name="datedFilename"/> 

        </New> 

      </Arg> 

    </New> 

 

    <!-- <Call class="org.mortbay.log.Log" name="info"><Arg>Redirecting stderr/stdout to <Ref id="ServerLogName"/></Arg></Call> 

    <Call class="java.lang.System" name="setErr"><Arg><Ref id="ServerLog"/></Arg></Call> 

    <Call class="java.lang.System" name="setOut"><Arg><Ref id="ServerLog"/></Arg></Call> 

     --> 

 

    <!-- =========================================================== --> 

    <!-- extra options                                               --> 

    <!-- =========================================================== --> 

    <Set name="stopAtShutdown">true</Set> 

    <Set name="sendServerVersion">true</Set> 

    <Set name="sendDateHeader">true</Set> 

    <Set name="gracefulShutdown">1000</Set> 

 

</Configure>

Notez surtout que j’ai utilisé 9090 comme valeur pour le port, au lieu du 8080.

Voilà. Il suffit ensuite d’ajouter ce fragment à votre configuration de lancement pour que Jetty utilise le port 9090.

Le style sera un peu minimaliste : je vais aller directement à l’essentiel et au pratique, sans détailler la théorie de la chose : je vais montrer comment faire telle chose, pas ce qu’elle est ou à quoi elle sert.

Commençons par un point simple : Comment créer une nouvelle nature de projet ?

1. Définir la classe de la nature

Dans le plug-in qui va définir cette nature, modifier le manifest (META-INF/MANIFEST.MF) pour ajouter le bundle org.eclipse.core.resources (qui définit l’interface IProjectNature ainsi que le point d’extension org.eclipse.core.resources.natures) et org.eclipse.core.runtime (qui définit CoreException) :

Require-Bundle: org.eclipse.core.resources, 

 org.eclipse.core.runtime

Créez ensuite une classe qui implémente org.eclipse.core.resources.IProjectNature :

package com.developpez.djo.howto.nature; 

 

import org.eclipse.core.resources.IProject; 

import org.eclipse.core.resources.IProjectNature; 

import org.eclipse.core.runtime.CoreException; 

 

public class DummyNature implements IProjectNature { 

  public static final String NATURE_ID = "com.developpez.djo.howto.nature.dummyNature"; 

 

  private IProject project; 

 

  public void configure() throws CoreException { 

 

  } 

 

  public void deconfigure() throws CoreException { 

 

  } 

 

  public IProject getProject() { 

    return project; 

  } 

 

  public void setProject(IProject project) { 

    this.project = project; 

  } 

}

Notez le champ NATURE_ID que j’ai mis en public car ça va servir pour récupérer l’identifiant de la nature lors de son affectation à un projet par exemple.

2. Déclarer la nature dans plugin.xml

Il faut ensuite déclarer la nature dans plugin.xml :
name= »Ma nature de projets »

<extension 

         id="dummyNature" 

         name="Ma nature de projets" 

         point="org.eclipse.core.resources.natures"> 

      <runtime> 

         <run 

               class="com.developpez.djo.howto.nature.DummyNature"> 

         </run> 

      </runtime> 

</extension>

N.B. (casse gueule)

Là il vous faut être attention : dans l’attribut id, il faut mettre seulement la partie de l’identifiant de la nature qui vient après l’identifiant du plugin.
Par exemple, dans ce cas ci, le plugin qui définit la nature a comme identifiant « com.developpez.djo.howto » (déclare dans le manifest) :

Bundle-SymbolicName: com.developpez.djo.howto.nature;singleton:=true

L’identifiant complet de la nature est calculé de cette façon :

<nom-symbloique-du-bundle> . <id-de-la-nature-tel-que-saisi-dans-plugin.xml> 

com.developpez.djo.howto.nature  . dummyNature

Ce qui donne : com.developpez.djo.howto.nature.dummyNature, et c’est cette valeur là qu’il faut mettre dans le champ NATURE_ID.

3. Associer une image (overlay) à la nature

Pour associer une image à la nature (c’est un overlay qui sera affiché au dessus de l’icône du dossier bleu d’un projet), il faut passer par un autre point d’extension qui est « org.eclipse.ui.ide.projectNatureImages » qui se trouve dans le plug-in « org.eclipse.ui.ide ». il vous faut donc ajouter ce plugin dans la section Require-Bundle du manifest (quoi que j’ai remarqué que même si j’ajoute pas une dépendance vers ce plugin, ça fonctionne quand même), et ensuite, dans plugin.xml, ajoutez :

<extension 

         point="org.eclipse.ui.ide.projectNatureImages"> 

      <image 

            icon="icons/dummy-nature.png" 

            id="com.developpez.djo.howto.nature.dummyNature.img" 

            natureId="com.developpez.djo.howto.nature.dummyNature"> 

      </image> 

</extension>

Dans icon, utilisez le nom relatif d’une icône (de petite taille de préférence, genre 8×8). Dans id, renseigner n’importe quoi du moment que ça reste unique et un identifiant valide. Personnellement, j’ajoute « .img » à l’id de la nature. Enfin, dans natureId, renseigner l’identifiant complet de la nature.

N.B. (casse gueule)

N’oubliez pas d’inclure le dossier icons dans le binary build.

4. Source

Projet Eclipse (dans un jar) : com.developpez.djo.howto.nature.source_1.0.0.jar

=> http://download.eclipse.org/releases/galileo/

Je viens de tester rapidement avec un Eclipse RCP Galileo M6, et j’ai pu installer Subversive et le Web Page Editor à partir de cet update-site.

[edit]Bon, après que j’ai installé le connecteur SVNKit du site de polarion, ça a été la cata xD … voilà, vous êtes prévenus :p

http://vikasrao.wordpress.com/2009/02/19/scala-nature-in-eclipse/

En gros, avec le nouveau plugin Scala, bien qu’il soit beacoup plus simple d’ajouter une nature Scala à un projet Java (clic droit, « Scala Tools> Add Scala Nature », ceci ne marche pas avec un projet de type « Dynamic web project » … exit donc ça ou ça

=> https://lampsvn.epfl.ch/trac/scala/ticket/1744

A noter que tous les packages d’Eclipse Ganymede sont disponibles dans cette version.

La version SDK est téléchargeable par ici :

=> http://download.eclipse.org/eclipse/downloads/drops/R-3.4.2-200902111700/index.php

A noter aussi que les packages (rcp, jee, etc.) ne sont pas encore directement disponibles dans la nouvelle version, dans la mesure où la page http://www.eclipse.org/downloads/ pointe toujours vers les versions SR1.
Toutefois, j’ai pu récupérer la version RCP en SR2, moyennant la modification de l’url de la SR1 de :

http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/ganymede/SR1/eclipse-rcp-ganymede-SR1-linux-gtk.tar.gz

à

http://www.eclipse.org/downloads/download.php?file=/technology/epp/downloads/release/ganymede/SR2/eclipse-rcp-ganymede-SR2-linux-gtk.tar.gz

:p

Et voici un rapport Bugzilla listant les points réglés pour la version 3.4.2 :

=> Rapport Bugzilla

Pour ce qui est des nouveautés, en voici quelques unes (un lien vers la liste complète est fourni à la fin du billet) :

• Platform / Equinox
  • Les IHMs d’installation/mise à jour de plugins continuent d’être retravaillés pour maximiser leur utilisabilité :
    
  • Inclusion d’une implémentation de l’RFC 138 (Composite Bundles) du futur OSGi 4.2.
  • Toujours dans le cadre de l’implémentation du futur OSGi 4.2, quelques ajouts à l’API core d’OSGi, comme org.osgi.framework.Bundle#getVersion() par exemple
• SWT
  • Le binding Cocoa de SWT n’est plus marqué comme « Early Access » et est désormais « Feature complete »
  • Le style SWT.SEARCH est désormais supporté sur toutes les plateformes
  • StyledText supporte les liens
• Platform UI
  • Ajout des fonctionnalités « Go To » et « Go Into » au projct Explorer dans un effort de l’amener à pied d’égalité avec le Package Explorer
  • Le style SWT.SEARCH est désormais supporté sur toutes les plateformes
  • StyledText supporte les liens
• JDT : Le tooling de développement Java
  • Possibilité de faire le rename refactor depuis le quick fix
  • Le JAr Exporter peut maintenant packager les dépendances sous forms de Jars dans le jar exporté ou à côté.
• PDE : Le tooling de développement de plug-ins Eclipse
  • Les préférences des target platforms ont été retravaillés
  • Là c’est mon favori sans le moindre doute : possiblité de définir les Start level des plugins dans Eclipse application launch configuration, comme ça l’est déjà pour OSGi framework launch configuration
  • La vue « Plugin Registry » permet désormais de requêter les services OSGi

=> Liste complète des nouveautés Nouveautés
=> Télécharger (la version SDK)

=> Si vous sautez le pas et décidez de tester l’une ou l’autre des versions Galileo, vous êtes encouragés à parler de vos impressions dans cette discussion dans le forum Eclipse Java :

Vos impressions sur Galileo (Eclipse 3.5) ?

Dans ce premier billet, je vais présenter l’étape de préparation de l’environnement de développement,et plus particulièrement la notation de Target Platform.

1. Présentation

Il s’agit ici de définir l’ensemble initial de plugins qui va constituer l’environnement d’exécution de notre serveur.

Il nous faut aussi configurer Eclipse pour qu’il reconnaisse et travaille sur cet ensemble de plugins.
Ca permettrait d’une part de limiter le nombre de choix présentés dans divers endroits (lors de sélection de plugins requis et des packages importés, des plugins à inclure dans une configuration d’exécution, etc.) mais aussi pour éviter une dépendance accidentelle à un plugin non désiré (je pense notamment aux plugins d’Eclipse par exemple)

2. Vue d’ensemble

La target platform sera constituée de :

• Equinox : C’est le coeur du serveur. Il implémente les spécifications OSGi et servira comme conteneur qui charge et gère le cycle de vie des autres plugins
• Spring Dynamic Modules : C’est une sorte de pont entre le monde OSGi (registre des services) et le monde de Spring (application context). De plus, Spring DM permet de faire tourner des applications Web Java ordinaires (Servlets, JSPs, etc.) dans un conteneur OSGi (OSGi offre un support basique pour le web à travers HttpService, mais c’est très limité)
• Spring : Il est là car tout d’abord il est requis par Spring DM, mais aussi pour son moteur IoC ainsi que les abstractions qu’il offre au dessus de plusieurs technologies Java (JDBC et Remoting entre autres)
• Jetty : Comme énoncé plus tôt, le HttpService d’OSGi est très limité parapport à la puissance dont on dispose dans une application web Java ordinaire. J’ai donc inclus Jetty dans la configuration de base de notre serveur pour avoir toute la puissance requise sous la main
• Quelques autre dépendances, comme des librairies de logging

Notez qu’il est tout à fait possible (et très simple) d’utiliser Tomcat à la place de Jetty. Ceci revient juste à remplacer les jars de Jetty par ceux de Tomcat.

3. Récupération des fichiers nécessaires

Il va nous falloir télécharger plusieurs packages pour retrouver les jars nécessaires.

• Spring DM : récupérable à cette adresse (pour cet article, j’ai utilisé Spring DM 1.2 M2)
• Spring Framework : récupérable à cette adresse (pour cet article, j’ai utilisé Spring Framework 2.5.6)

Après avoir extrait les archives de Spring et de Spring DM, Créez quelque part sur votre disque un dossier qui servira à rassembler les jars de la target platform, par exemple  » server-springdm-1.2.0.m2-spring-2.5.6-jetty  » dans mon cas.

Généralement, je crée la target platform en tant que projet (simple) dans mon worksapce Eclipse, histoire de pouvoir le versionner sur SVN par exemple, mais ce n’est pas requis.

Copiez les fichiers suivants depuis le dossier où vous avez extrait Spring DM vers le dossier de la target platform:

• spring-osgi-1.2.0-m2/dist/spring-osgi-core-1.2.0-m2.jar
• spring-osgi-1.2.0-m2/dist/spring-osgi-extender-1.2.0-m2.jar
• spring-osgi-1.2.0-m2/dist/spring-osgi-io-1.2.0-m2.jar
• spring-osgi-1.2.0-m2/dist/spring-osgi-web-1.2.0-m2.jar
• spring-osgi-1.2.0-m2/dist/spring-osgi-web-extender-1.2.0-m2.jar

• spring-osgi-1.2.0-m2/lib/com.springsource.net.sf.cglib-2.1.3.jar
• spring-osgi-1.2.0-m2/lib/com.springsource.org.aopalliance-1.0.0.jar
• spring-osgi-1.2.0-m2/lib/com.springsource.slf4j.api-1.5.0.jar
• spring-osgi-1.2.0-m2/lib/com.springsource.slf4j.log4j-1.5.0.jar
• spring-osgi-1.2.0-m2/lib/com.springsource.slf4j.org.apache.commons.logging-1.5.0.jar
• spring-osgi-1.2.0-m2/lib/jetty-6.1.9.jar
• spring-osgi-1.2.0-m2/lib/jetty.start.osgi-1.0.0.jar
• spring-osgi-1.2.0-m2/lib/jetty-util-6.1.9.jar
• spring-osgi-1.2.0-m2/lib/jetty.web.extender.fragment.osgi-1.0.1.jar
• spring-osgi-1.2.0-m2/lib/log4j.osgi-1.2.15-SNAPSHOT.jar
• spring-osgi-1.2.0-m2/lib/org.eclipse.osgi-3.2.2.jar
• spring-osgi-1.2.0-m2/lib/servlet-api.osgi-2.5-SNAPSHOT.jar

• spring-framework-2.5.6/dist/modules/spring-aop.jar
• spring-framework-2.5.6/dist/modules/spring-beans.jar
• spring-framework-2.5.6/dist/modules/spring-context.jar
• spring-framework-2.5.6/dist/modules/spring-core.jar
• spring-framework-2.5.6/dist/modules/spring-jdbc.jar
• spring-framework-2.5.6/dist/modules/spring-tx.jar
• spring-framework-2.5.6/dist/modules/spring-web.jar
• spring-framework-2.5.6/dist/modules/spring-webmvc.jar

Pour vous simplifier la tache, vous pouvez télécharger cet archive zip (5 Mo) qui contient la target platform décrite plus haut)

4. Configuration d’Eclipse

Dans Eclipse, allez au menu Window -> Preferences et localisez le noeud « Plug-in Development/Target Platform »

Cliquez sur « Browse », localiser le dossier de la target platform et validez.

Il nous faut maintenant créer une configuration de lancement qui lance notre serveur.

Faites un clic sur le petit flêche orienté vers le bas du bouton Run et sélectionnez « Run configurations »

Sélectionnez le noeud « OSGi Framework », puis clic droit et « New »

Saisissez un nom pour cette configuration, « serveur » par exemple.
Par défaut, tous les plugins de la target platform sont cochés. Faites le si ce n’est pas le cas.

Assurez vous aussi que « Default start level » est positionné à 4 et que « Default-Autostart » est à true

Il faut maintenant modifer le start level des deux extenders de Spring DM (org.springframework.osgi.extender et org.springframework.osgi.web.extender) pour les mettre à 5

Cliquez sur « Apply » pour valider.

5. Test

Cliquez sur le bouton « Run ». La console devrait afficher :

Et si vous tapez l’adresse « http://localhost:8080/ » dans un navigateur, vous devriez avoir :

Pour ce qui est des nouveautés, en voici quelques unes (un lien vers la liste complète est fourni à la fin du billet) :

• Platform
  • Cocoa a été porté sur 64bits
  • La boite de dialogue « customize perspective » permet désormais de configurer les éléments des menus
  • Le composant FilteredTree (utilisé dans les préférences par exemple) a été retravaillé visuellement
    
  • Jetty 6.1 remplace Jetty 5.1
• SWT
  • Possiblité d’appeler du code Java à partir de JavaScript dans le widget Browser, et vice-versa
  • Le composant StyledText permet désormais la sélection par bloc
• JDT : Le tooling de développement Java
  • Possibilité de supprimer/cacher les working sets via l’action « supprimer » à partir du Package Explorer
  • Nouvelle option lors du formatage pour garder les retours à la ligne
• PDE : Le tooling de développement de plug-ins Eclipse
  • Amélioration de l’éditeur du produit, ce qui permet de spécifier les états de démarrage des plugins

=> Liste complète des nouveautés Nouveautés
=> Télécharger (la version SDK)

=> Si vous sautez le pas et décidez de tester l’une ou l’autre des versions Galileo, vous êtes encouragés à parler de vos impressions dans cette discussion dans le forum Eclipse Java :

Vos impressions sur Galileo (Eclipse 3.5) ?

1. Vue d’ensemble

L’application que je vais utiliser comme exemple est simpliste : elle ne sert qu’à afficher une liste de personnes (peu importe comment cette liste est retrouvée) dans une page web.

Seulement, histoire de faire propre, je vais découper cette application en 4 bundles:

1. domain: C’est un bundle qui définit les objets métier (un seul dans notre cas: Person)
2. service-api: C’est un bundle qui définit les interfaces (contrats) de la couche métier
3. service-impl: C’est un bundle qui définit les implémentations des services mais aussi les exporte en tant que services OSGi qui seront consommés par le dernier bundle.
4. web-frontend: C’est un bundle qui définit le front-end web de l’application et qui consomme les services exposés par service-impl

N.B.: Je suppose tout au long de ce billet que le serveur S2AP ainsi que le tooling Eclipse correspondant est déjà en place comme je le montre ici.

2. Créer le bundle domain

Dans Eclipse, lancez le wizard « New Bundle Project » :

Saisissez un nom parlant pour ce bundle (djo.s2ap.demo.domain pour moi) et cliquez sur Next.
Là, et c’est une nouveauté dans le tooling S2AP pour Eclipse (sur une suggestion de ma part, merci à Christian Dupuis qui l’a implémenté), il est possible de choisir le type du bundle (None ou Web) :

Choissisez None et validez.
Créer un package dans le dossier src (j’utilise habituellement le nom du projet comme package de base), et créez une classe Person (forcément, mon type de données préféré )

package djo.s2ap.demo.domain; 

 

public class Person { 

  private String name; 

  private int age; 

 

  public Person(String name, int age) { 

    super(); 

    this.name = name; 

    this.age = age; 

  } 

 

  public String getName() { 

    return name; 

  } 

 

  public void setName(String name) { 

    this.name = name; 

  } 

 

  public int getAge() { 

    return age; 

  } 

 

  public void setAge(int age) { 

    this.age = age; 

  } 

 

}

Je vais me contenter de cette classe comme mon domaine.

Il faut ensuite exporter le package de cette classe pour qu’elle soit visible aux autres bundles.
Pour ce faire, localisez le fichier src/META-INF/MANIFEST.MF et double-cliquez la dessus, ce qui ouvre l’éditeur de manifest de STS (encore une fonctionnalité proposé par l’auteur de ce billet (moi) et implémentée par l’equipe STS (re-merci) !).
Dans l’éditeur multi-pages qui se lance, localisez la page « Runtime » et activer la.
A gauche, vous trouverez une liste présentant les packages exportés par le bundle en question. Cliquez sur le bouton « Add » et dans la fenêtre qui s’affiche, sélectionnez l’unique package présent (djo.s2ap.demo.domain).

Sinon, il est toujours possible de travailler directement sur le manifest en utilisant le contenu suivant:

Manifest-Version: 1.0 

Bundle-Version: 1.0.0 

Bundle-Name: Domain Bundle 

Bundle-ManifestVersion: 2 

Bundle-SymbolicName: djo.s2ap.demo.domain 

Export-Package: djo.s2ap.demo.domain

Voilà, le premier bundle est prêt.

3. Créer le bundle service-api

Comme énoncé plus haut, ce bundle va juste définir les contrats des services (sous forme d’interfaces). C’est LE pattern OSGi à mon avis, i.e. séparer l’interface de l’implémentation dans des bundles différents, histoire de pouvoir changer (mettre à jour, corriger des bugs, peaufiner, etc.) l’implémentation séparément de son interface mais aussi pour éviter que le consommateur d’un service ne dépende de son implémentation.

Dans le cadre de cette application exemple, je vais me contenter d’un seul service exposant une seule fonctionnalité qui est de récupérer une liste de personnes.

Commencez par créer un autre bundle nommé « djo.s2ap.demo.service.api » dans mon cas (même procédure que pour le bundle domain, choisissez « None » comme personality).
Ce bundle aura besoin de voir la classe Person du bundle domain.
Or, justement, j’ai exporté le package contenant cette classe. Il ne reste plus qu’à importer ce package dans le bundle service.api.

Pour ce faire, localisez et double-cliquez sur le fichier « src/META-INF/MANIFEST.MF » du bundle service.api.
Dans l’éditeur multi-pages qui s’affiche, activez la page « Dependencies ».
Dans la liste à gauche (Import Package », cliquez sur Add, et localisez le package « djo.s2ap.demo.domain » contenant la classe Person (utilisez le filtre):

Sélectionnez ce package et validez.
Ainsi, la classe Person devient visible dans le second bundle.

Créez ensuite un package « djo.s2ap.demo.service.api » avec une interface IPersonRepository dont voici le code:

package djo.s2ap.demo.service.api; 

 

import java.util.List; 

 

import djo.s2ap.demo.domain.Person; 

 

public interface IPersonRepository { 

  List<Person> getPersonsList(); 

}

Pour finir, il faut exporter le package qui définit cette interface car l’implémentation de ce service aura besoin d’y accéder.
Donc, comme montré plus haut, exportez le package « djo.s2ap.demo.service.api » en utilisant soit l’editeur graphique du manifest ou en jouant directement sur le manifest.

4. to be continued

Faute d’espace et de temps, je vais m’arrêter là pour ce billet et je finirais la chose bientôt dans un autre billet.

Toujours faute de temps, mais aussi à cause du fait que j’ai abandonné S2DMS, j’arrive pas à finir le second volet
J’espère au moins pouvoir parler des raisons du pourquoi j’ai abandonné cette plateforme (1 raison plus précisément, la notion de PAR)