\section{La direction de GeoTools}
\label{sec:geotools}
\begin{small}Cet article a \'et\'e r\'edig\'e pendant le premier trimestre 2007 
et donne un aper\c{c}u du d\'eveloppement de la communaut\'e et des objectifs 
de recherche\end{small}
\newline
\emph{par Jody Garnett, traduit par Sidonie Christophe}

\subsection{Communaut\'e d'utilisateurs}
\label{subsec:users_GN}
GeoTools a de nouveau relanc\'e la production mensuelle de versions 
majeures. La publication de ces versions r\'eguli\`eres aide \`a la 
visibilit\'e des progr\`es et \`a l'accessibilit\'e \`a la communaut\'e d'utilisateurs. 
Nous n'avons pas fait \'etat de ceci, hormis dans la liste 
d'utilisateurs, car ces versions sont strictement r\'eserv\'ees \`a un "acc\`es anticip\'e".
\begin{itemize}
 \item 
\htmladdnormallink{2.4-M0}{http://docs.codehaus.org/display/GEOTOOLS/2.4-M0}
 \item 
\htmladdnormallink{2.4-M1}{http://docs.codehaus.org/display/GEOTOOLS/2.4-M1}
\end{itemize}
Nous avons aussi mis \`a jour notre page Web \htmladdnormallink{Module 
Matrix}{http://docs.codehaus.org/display/GEOTOOLS/Module+Matrix} (ainsi 
que celle de nos politiques de d\'eveloppement) afin de mettre en \'evidence 
les diff\'erences de gestion des modules.

\subsection{D\'eveloppement}
\label{subsec:development_GN}
En ce moment nous travaillons \`a la fois sur plusieurs projets pay\'es 
(avec des dates limite) et sur la pr\'esentation de Martin au groupe de 
travail sur la GeoAPI (rencontre OGC de cet \'et\'e?).

%\setkeys{Gin}{width=1\textwidth}
\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots 
etc)/PDF (drawings) format:
   \includegraphics[scale=0.95]{dev_announce/geotools/tracks.png}
   %caption of the figure
   \caption{Le code couleur du diagramme ci-dessus est bas\'e \`a la fois 
sur le projet concern\'e et l'activit\'e de d\'eveloppement (l'intensit\'e de la 
couleur indique le taux d'activit\'e).}
   %label of the figure, which has to correspond to \ref{}:
   %\label{fig:label_of_your_image}
\end{figure}


\subsection{Axes de d\'eveloppement}
\label{subsec:policies_GN}
Depuis le dernier trimestre 2006, les axes de d\'eveloppement des projets 
GeoTools et GeoServer ont \'et\'e modifi\'es :
\begin{itemize}
 \item \htmladdnormallink{GEOT : Proposition de modification 
GeoTools}{http://docs.codehaus.org/display/GEOT/GeoTools+change+proposal} - 
Modifier l'API existante
 \item \htmladdnormallink{GEOT : G\'erer votre 
module}{http://docs.codehaus.org/display/GEOT/Supporting+your+module} - Ajouter 
un nouveau module \`a GeoTools
 \item \htmladdnormallink{GEOS : GSIP 
6}{http://docs.codehaus.org/display/GEOS/GSIP+6+-+Track+GeoTools+Trunk} - 
Suivez le tronc commun GeoTools
\end{itemize}
L'objectif des axes ci-dessus est d'obtenir une ramification uDig et 
GeoServer disponible, bas\'ee sur la version tronc commun GeoTools, sans 
laquelle nous ne sommes qu'une communaut\'e de d\'eveloppement dispers\'ee sur 
diff\'erentes versions (tendant certes toutes \`a \^etre actives).

La modification d'un axe de d\'eveloppement a \'et\'e planifi\'ee:
\begin{itemize}
\item Quand l'accord d'un contributeur est disponible (apr\`es 
n\'egociations avec l'Osgeo), nous demanderons \`a chaque d\'eveloppeur de signer 
quelque chose.
\end{itemize}

\subsection{Objectifs de recherche}
\label{subsec:research_GN}
Il y a plusieurs pistes pour la recherche en cours, et quelques 
probl\`emes de conception non r\'esolus.

\begin{figure}[htbp]
   \centering
   %name of your graphic, without the path AND in PNG (screnshots 
etc)/PDF (drawings) format :
   \includegraphics[scale=0.95]{dev_announce/geotools/research.png}
\end{figure}

\subsection{Etapes de recherche}
\label{subsec:policies_GN}
Les projets GeoTools et GeoServer apportent quelques modifications de 
principe, en accord avec la recherche en cours.
\begin{itemize}
\item \htmladdnormallink{GEOT : Cr\'eer votre propre 
module}{http://docs.codehaus.org/display/GEOT/Creating+your+own+Module}
\end{itemize}
L'introduction d'un espace pour modules ``non support\'es'' dans GeoTools 
est parvenu \`a rendre visible des recherches qui \'etaient jusque l\`a "hors 
de vue, hors de pens\'ee". Les projets  uDig et GeoServer ont d\'ej\`a des 
sections communautaires remplissant ces besoins.

\subsection{Dates limites connues}
\label{deadlines_GN}
Dans le diagramme ci-dessus, les dates limite connues sont soulign\'ees.

Voici les dates qui ont \'et\'e rendues publiques :
\begin{itemize}
\item Article GeoAPI pour le 11 Juin (code bloqu\'e le 11 Mai)
    \begin{itemize}
    \item Relecture de l'article pendant les 
\htmladdnormallink{Rencontres du 9 Juillet}{http://www.opengeospatial.org/event/0707tc} du groupe 
de travail
    \item L'article doit \^etre soumis le 11 Juin, dernier d\'elai (cad un 
mois avant).
    \item La derni\`ere fois cet article a mis un mois \`a \^etre finalis\'e, 
donc le code est bloqu\'e le 11 Mai pour les besoins de l'article.  
\end{itemize}
    \item Impl\'ementation de GeoTools ISO Geometry pour mi-Mars.
    \begin{itemize}
    \item jstWrapper ou Geometry peut \^etre termin\'e suivant le soutien apport\'e
    \item Le module ne sera peut-\^etre pas inclus dans le t\'el\'echargement 
tant que Java 5 n'est pas disponible.\end{itemize}

\end{itemize}

Le paragraphe suivant pr\'esente les objectifs de recherche uniquement 
(pas de version officielle requise) :
\begin{itemize}
\item GeoTools Feature / sch\'ema de la communaut\'e GeoServer pour mi-Mars
    \begin{itemize}
    \item l'impl\'ementation sera disponible en tant que module non 
support\'e, l'int\'egration se fera plus tard.                                                                
\end{itemize}
\end{itemize}

\subsection{Probl\`emes restants}
\label{subsec:problems_GN}
Les probl\`emes suivants sont list\'es comme des probl\`emes de conception 
auxquels il faut s'attaquer. Ces probl\`emes arr\^etent souvent les travaux 
pay\'es, mais par l'importance de la collaboration n\'ecessaire se 
retrouvent sans financement sp\'ecifiques.

\begin{itemize}
\item \textbf{GeoAPI TypeName} - Nous sommes coinc\'es entre la 
d\'efinition ISO de GenericName (entre autres le Sch\'ema dont les noms doivent \^etre 
connus 
avant construction) et la n\'ecessit\'e d'avoir un "identifiant" rapide quand 
on recherche le contenu d'une entit\'e. C'est un exemple de combinaisons  
de choix pour la facilit\'e d'utilisation .. difficile \`a r\'esoudre. La 
classe Java QName est un exemple d'un bon compromis (bas\'e sur la m\^eme 
sp\'ecification ISO).
        \begin{itemize}
	\item L'interface GeoAPI TypeName a \'et\'e d\'efinie en suivant le format 
QName, entrant en conflit avec l'interface pour GenericName
	\end{itemize}
\item \textbf{GeoTools ConnectionPool} - GeoTools commence \`a \^etre 
utilis\'e dans des applications J2EE plus importantes, et ainsi, nous devons 
utiliser une recherche type JNDI pour nos DataSource (l'utilisation 
d'une ConnectionPool Oracle est la plus souvent demand\'ee sur la liste 
utilisateur).
        \begin{itemize}
	\item Nous avons besoin de d\'efinir une approche, de la documenter et 
de l'\'etendre aux datastores et aux plugins d'autorit\'e des bases de donn\'ees 
epsg.\end{itemize}
\item \textbf{GeoTools FilterCapabilities} - Nous utilisons maintenant 
les interfaces filtres GeoAPI. L'interface "Function" ne fournit pas le 
nombre de param\`etres requis ; l'information est r\'ecup\'er\'ee comme une 
partie de l'information FilterCapabilities (que nous n'utilisons pas 
couramment).
        \begin{itemize}
	\item Nous devons s\'eparer la description des fonctions disponibles de 
la structure des donn\'ees utilis\'ee pour d\'efinir une expression. 
\end{itemize}
\item \textbf{GeoServer Persistence} - La capacit\'e de persistance de 
l'\'etat de GeoServer (dans un fichier XML) est difficile \`a maintenir et 
non extensible.
	\begin{itemize}
	\item Nous avons plusieurs sources d'inspiration (utilisation de XML 
pour les technologies bean), quelques restrictions (permettant de la 
configuration programmatique) et quelques tests d'acceptation (aptitude \`a 
ajouter des \'el\'ements de configuration additionnels sans changer le 
mod\`ele objet). \end{itemize}
\item \textbf{GeoServer Catalog} - Un catalogue est utilis\'e pour g\'erer 
les connexions aux ressources, et permet des ajouts d'autres types de 
ressources dans le temps. L'approche existante (couper \verb|&| coller) 
n'est pas bien adapt\'ee \`a l'\'echelle de travail de GeoServer.
        \begin{itemize}
	\item Nous devons ramener les interfaces GeoTools au m\^eme niveau que 
celles utilis\'ees dans GeoServer et uDig. Il existe beaucoup d'exemples 
n\'egatifs (sur ce que nous ne voulons pas faire) et quelques bonnes 
id\'ees. GeoTools doit s'\'evertuer \`a construire un terrain minimum 
commun.\end{itemize}
\item \textbf{GeoServer J2EE} - GeoServer doit devenir une meilleure 
aplication J2EE.
        \begin{itemize}
	\item Faites attention aux DataSources renvoy\'ees via une recherche 
JNDI
	\item Configuration du support externe et clustering                        
\end{itemize}
\item \textbf{uDig Rendering} - Le syst\`eme de rendu de uDig ayant \'et\'e 
suffisamment utilis\'e en conditions r\'eelles, nous pouvons commencer \`a le 
simplifier de fa\c{c}on exp\'erimentale. Selon les limites que l'on se pose, 
nous sommes capables d'ajouter de l'OpenGL \`a notre liste de cibles (SWT 
et AWT sont support\'es \`a pr\'esent).
        \begin{itemize}
	\item M\^eme si le travail pourrait \^etre r\'etribu\'e dans GeoTools, nous 
devons nous assurer qu'il y a une bonne raison (mesur\'ee en d\'eveloppeurs) 
de rendre cet effort valable.   \end{itemize}
\item \textbf{uDig Catalog} - Le syst\`eme de catalogue de uDig ayant \'et\'e 
suffisamment utilis\'e en condition r\'eelles, nous pouvons commencer \`a le 
simplifier de façon exp\'erimentale.
        \begin{itemize}
	\item M\^eme si le travail pourrait \^etre r\'etribu\'e dans GeoTools, nous 
devons nous assurer qu'il y a une bonne raison (mesur\'ee en d\'eveloppeurs) 
de rendre cet effort valable. \end{itemize}

\end{itemize}