Discussion :

[joel.drigo]

Salut,

je travaille sur une application Eclipse RCP 3.5 et pour contourner un défaut dans une classe de jface, j'ai fait un fragment contenant ma classe de contournement.

J'ai un plugin qui dépend de org.eclipse.ui dans lequel j'ai une classe qui étend cette classe de contournement.

Cette classe, org.eclipse.jface.viewers.AbstractStyledCellLabelProvider, étend org.eclipse.jface.viewers.OwnerDrawLabelProvider (du plugin org.eclipse.jface, la dépendance sur ce plugin étant héritée de la dépendance sur org.eclipse.ui)

Tout fonctionne bien quand j'exécute mon application dans Eclipse.

On build l'application sur un serveur luntbuild avec un script ant, qui pilote pde à ce que j'ai compris.

Le problème c'est que la build plante. J'obtiens des :

Restriction d'accès : Le type AbstractStyledCellLabelProvider n'est pas accessible en raison d'une restriction pesant sur l'entrée du chemin d'accès aux classes /opt/luntbuild-1.6/work/Open4-LC/plugins/fr.wedia.util.fragments.jface/@dot

je ne vois pas du tout ou j'aurais des restrictions d'accès, ou comment et où indiquer quoique ce soit pour éviter ce problème.

[Mickael_Istria]

Est-ce que ton plugin exporte bien le package contenant la classe via la directive Export-Package?
Aussi, sache que Equinox et p2 ont parfois du mal avec les "split-packages" (2 bundles différents qui exportent le même package). Donc il vaut mieux que tu donnes un autre nom de package à ta classe. Quelque chose comme fr.wedia.util.fragments.jface au lieu de org.eclipse.jface.viewers.

[joel.drigo]

Merci pour ta réponse rapide

Est-ce que ton plugin exporte bien le package contenant la classe via la directive Export-Package?

Oui. J'ai essayé aussi en enlevant cette directive, sans succès.

Aussi, sache que Equinox et p2 ont parfois du mal avec les "split-packages" (2 bundles différents qui exportent le même package). Donc il vaut mieux que tu donnes un autre nom de package à ta classe. Quelque chose comme fr.wedia.util.fragments.jface au lieu de org.eclipse.jface.viewers.

Je me doutais bien que je pouvais avoir des problèmes avec ce genre de chose, mais pour le coup, si j'ai choisi le même package, c'est contraint et forcé : mon but est de pouvoir accèder à aux méthodes protected de OwnerDrawLabelProvider et ViewerCell. Pour le détail, en fait, je cherchais à contourner le problème de l'alignement non géré dans le StyledCellLabelProvider. Et le seul moyen que j'ai trouvé c'est dupliquer le code de StyledCellLabelProvider, dans le même package (d'ou le besoin de faire un fragment d'ailleurs).

Je suis entrain de tenter une autre solution, par réflexion, parce que je trouve pas de solution pour builder mes fragments. Mais je ne suis pas sur de réussir aussi avec la solution par réflexion à cause des droits sur les accessibles dotés par osgi...

[Mickael_Istria]

Ok, je crois comprendre.
Ce que tu peux tenter c'est:

1. créer ton bundle fr.wedia.util.jface (pas un fragment)
2. faire dépendre de ce bundle du bundle org.eclipse.jface.
3. créer une classe org.eclipse.jface.viewers.PublicOwnerDrawLabelProvider qui étend OwnerDrawLabelProvider, et qui rend les méthodes que tu veux publique (public methode() { super.methode(); }). Tu n'exportes *pas* le package org.eclipse.jface.viewers qui sera du coup interne au bundle.
4. créer ta classe fr.wedia.util.jface.viewers.AbstractStyledCellLabelProvider qui étend PublicOwnerDrawProvider, tu implémentes ce que tu veux dedans
5. exporter le package fr.wedia.util.jface.viewer

Les bundles qui utilisent AbstractStyledCellLabelProvider peuvent donc faire un Require-Bundle sur fr.wedia.util.jface sans risque de confusion et auront accès à AbstractStyledCellLabelProvider.

Est-ce que le problème pour lequel tu essaies de faire un workaround est reporté dans le bugtracker d'Eclipse? Si non, je t'invite à le faire, et éventuellement à fournir le patch. Ça pourrait faire partie de la 4.4.

[joel.drigo]

Ok, je crois comprendre.
Ce que tu peux tenter c'est:

1. creer ton bundle fr.wedia.util.jface (pas un fragment)
2. faire dependre de ce bundle du bundle org.eclipse.jface.
3. creer une classe org.eclipse.jface.viewers.PublicOwnerDrawLabelProvider qui etend OwnerDrawLabelProvider, et qui rend les methodes que tu veux publique (public methode() { super.methode(); }). Tu n'exportes *pas* le package org.eclipse.jface.viewers qui sera du coup interne au bundle.
4. creer ta classe fr.wedia.util.jface.viewers.AbstractStyledCellLabelProvider qui etend PublicOwnerDrawProvider, tu implementes ce que tu veux dedans
5. exporter le package fr.wedia.util.jface.viewer

Les bundles qui utilisent AbstractStyledCellLabelProvider peuvent donc faire un Require-Bundle sur fr.wedia.util.jface sans risque de confusion et auront acces a AbstractStyledCellLabelProvider.

Merci. J'ai pensé à un moment de faire une seconde classe dans un autre package, mais je pensais être obligé de faire un fragment pour pouvoir accèder aux membres protected du package et des classes du package, et surtout au constructeur privé de ViewerCell ()... je vais tenter ta solution.
Pour l'instant ma solution à base de réflexion fonctionne (mais bien sûr elle a un gros défaut, c'est que la méthode étant appelé par réflexion (getViewerCell(Event,Object)) est très appelée, donc ça va être très impactant pour la charge). Donc, si je peux le faire sans, c'est beaucoup mieux.

Est-ce que le probleme pour lequel tu essaies de faire un workaround est reporte dans le bugtracker d'Eclipse? Si non, je t'invite a le faire, et eventuellement a fournir le patch. Ca pourrait faire partie de la 4.4.

J'ai pas encore regardé sur le bugtracker d'Eclipse, mais j'ai vu pas mal de forums en anglais (comme stackoverflow.com) où des personnes parlaient de ce problème d'alignement. Y'a même des solutions fausses qui sont données (utiliser SWT.RIGHT_TO_LEFT comme style ). Y'en a un qui suggère de dupliquer StyledCellLabelProvider mais sans indiquer comment organiser ses plugins (je suppose qu'il n'était pas aller voir qu'il y avait des méthodes et classes protected)
Je ne suis pas certain que ça soit vraiment un bug. Ca semble tellement facile à faire, et tellement évident à prendre en compte. On dirait un simple oubli de specs. Mais qui dure depuis 8 versions. Comme si j'étais le seul à vouloir cadrer à droite des colonnes rendues par StyledCellLabelProvider
J'attendais d'avoir régler le problème de mon côté avant de regarder si ça n'était pas réglé dans la dernière version de jface. Après je contacterai Eclipse. Non sans avoir mis la solution complète ici, bien sûr

Depuis ce matin, j'ai continué à chercher sur le web, et j'ai trouvé le projet UI-BINDINGS ou ils font exactement comme moi (un fragment, la même implémentation à 1 ou 2 détails près (pas le même nom de classe quand même), et tout le paramétrage est identique au mien : mais aucun de leur code n'utilise cette classe, donc je ne suis pas sur qu'ils l'aient fait fonctionner. En tout cas ça montre que le problème est connu.


Merci encore pour la suggestion Je me lance... à plus tard...

[joel.drigo]

Ca ne fonctionne pas malheureusement.

J'ai exactement l'erreur que je pensais avoir et qui m'a fait m'orienter directement vers un fragment :

java.lang.IllegalAccessError: tried to access method org.eclipse.jface.viewers.ColumnViewer.getViewerRowFromItem(Lorg/eclipse/swt/widgets/WidgetLorg/eclipse/jface/viewers/ViewerRow; from class org.eclipse.jface.viewers.AbstractStyledCellLabelProvider
at org.eclipse.jface.viewers.AbstractStyledCellLabelProvider.getViewerCell(AbstractStyledCellLabelProvider.java:267)

Je vais tenter de revenir à un fragment, mais on conservant ta suggestion de structure de package. Mais ce sera pour demain

[Mickael_Istria]

Je ne suis pas certain que ça soit vraiment un bug.

Si, en tant qu'utilisateur de l'API, elle ne se comporte pas vraiment comme attendu, on peut dire que c'est un bug.

J'ai pas encore regardé sur le bugtracker d'Eclipse, mais j'ai vu pas mal de forums en anglais (comme stackoverflow.com) où des personnes parlaient de ce problème d'alignement.
[...]
Ca semble tellement facile à faire, et tellement évident à prendre en compte.

Pour info, stackoverflow n'est pas pris en compte par les contributeurs Eclipse lorsqu'il s'agit de fixer des bugs. StackOverflow c'est trop la foire au n'importe quoi, c'est bon à aider les nouveaux venus et à les faire rentré dans la communauté, mais en aucun cas il ne faut croire que les développeurs qui bossent sur JFace monitorent StackOverflow, et en aucun cas, il ne faut croire que si quelqu'un en parle quelque part, les contributeurs sont au courant.
Le seul moyen d'être sûr que l'équipe de développeurs en prenne connaissance c'est de le mettre dans le bugtracker. Si ça n'y est pas, alors l'équipe ne connait vraisemblablement pas le problème.

Pour la plupart des projets OSS: les utilisateurs ont des use-cases qui ne sont peut-être même pas imaginés par les équipes de développement, mais tiennent pour acquis que ça doit marcher en l'état et sont prêts à accepter des bugs en croyant que c'est normal si c'est là depuis 8 versions.
Non! Ne vous laissez pas faire! C'est un bug, point-barre. L'utilisateur est le roi et décide de ce qui est un bug ou pas
Les bugs qui sont la, les développeurs ne les connaissent surement pas, et si personne les mets dans le tracker, il ne seront jamais fixés.

Donc voila, j'insiste, mais au final, le bugtracker est la source d'info et de reporting quand tu as quelque chose qui semble être un bug. Utilisez-le beaucoup! Même si vous n'êtes pas surs que c'est un bug, c'est pas grave; c'est la responsabilité des développeurs de prendre en compte la difficulté de certains use-cases.

[joel.drigo]

Salut,

excellente nouvelle : ça fonctionne ! Avec un fragment donc, mais la structure de packages que tu as suggérée.

Merci encore pour la suggestion

Je repasserai plus tard pour résumer la mise en place avec le source ici, afin que d'autres personnes qui seraient interessés par le workaround puissent l'appliquer.

Par ailleurs, j'ai regardé sur le bug tracker d'eclipse et j'ai vu une discussion sur le sujet. Le patch fourni est similaire à mon implémentation, mais pas complètement.
il manque un aspect important, pourtant signalé par un intervenant : pouvoir surcharger l'alignement spécifiquement pour le provider.
Je vais chercher par ailleurs si ce n'est pas résolu, ou demandé, autrement, parce qu'en théorie, la bonne solution devrait être en effet différente (pour le détail, je voulais profiter de l'utilisation d'un StyledCellLabelProvider pour aligner la colonne différemment de son entête : mais à mon avis, une vraie bonne solution serait d'avoir cette feature quelque soit le LabelProvider, donc gérée au niveau de la colonne).

[Mickael_Istria]

Par ailleurs, j'ai regardé sur le bug tracker d'eclipse et j'ai vu une discussion sur le sujet. Le patch fourni est similaire à mon implémentation, mais pas complètement.
il manque un aspect important, pourtant signalé par un intervenant : pouvoir surcharger l'alignement spécifiquement pour le provider.
Je vais chercher par ailleurs si ce n'est pas résolu, ou demandé, autrement, parce qu'en théorie, la bonne solution devrait être en effet différente (pour le détail, je voulais profiter de l'utilisation d'un StyledCellLabelProvider pour aligner la colonne différemment de son entête : mais à mon avis, une vraie bonne solution serait d'avoir cette feature quelque soit le LabelProvider, donc gérée au niveau de la colonne).

Cool, tu devrais ajouter ça à la discussion, peut-être même que tu peux contribuer un patch

[joel.drigo]

En conclusion de cette discussion, et avant de la passer en Résolu, je fais un résumé complet de la solution mise en place, pour ceux qui aurait le même problème, ou similaire.

Le contexte

Je suis responsable (conception et developpements) d'une application client-lourd Eclipse RCP (3.5 java 1.5, prévue pour évoluer en Kepler (ou Luna plus tard) 1.7 d'ici la fin de l'année ou début d'année prochaine, selon les priorités du planning).
Il s'agit d'un socle d'un peu plus de 2 millions de lignes de code, destiné à être intégré par des équipes d'intégration pour l'adapter aux spécificités de chacun de nos clients.
L'un des composants fournis, appelé dans notre jargon métier, "corbeille", est un système permettant une visualisation de données selon différentes présentations (liste, arbre, galerie) produites à base de viewers JFACE (ou NEBULA, pour la galerie), et offrant différentes fonctionnalités de base (tris, filtres, rafraichissement automatique, etc...). Les informations affichées étant, éventuellement, rafraîchîes dynamiquement en temps réel sur évènements provenant du serveur.
Le composant produit à l'origine, datant de 4 ans, était formé de 6 abstractions, permettant à l'intégrateur de fournir les implémentations du LabelProvider, ContentProvider, etc... Un toolkit était fourni aux intégrateurs pour leur faciliter l'implémentation, mais cette implémentation demandait un certain temps et des compétences certaines, et l'intégration pouvait en souffrir, tant au niveau performances, qu'au niveau fonctionnel.

Le besoin

J'ai donc décidé de fournir un nouveau composant beaucoup plus complet, beaucoup plus fonctionnel, prenant en charge de nombreux traitements techniques un peu "touchy", afin de limiter les développements nécessaires au niveau du projet à de la configuration pure au maximum, sans fermer les possibilités d'implémentations plus spécifiques.
J'en ai profité pour ajouter certaines fonctionnalités demandées par nos clients depuis un moment et qui étaient le plus souvent réalisés au besoin, donc plusieurs fois, par les équipes d'intégrations, par des surcharges de classe, ou des redéfinitions de fabriques.

Dans ces nouvelles fonctionnalités, il y a, entre autres, la possibilité de styler les textes affichés dans les cellules. Pour réaliser cette fonctionnalité, je suis parti tout naturellement du StyledCellLabelProvider de JFACE.

Mais j'ai été rapidement confronté à un problème de taille : ce composant aligne toujours à gauche, ignorant le style de la colonne.

J'ai donc décidé d'inclure cette possibilité moi-même, tout d'abord, par surcharge.

De plus, on voulait pouvoir cadrer les colonnes de nombres ou de date à droite (tout logiquement), et le centrage des colonnes d'icônes (qu'on utilisait par exemple pour afficher les booléens et les énumérations) tout en conservant un cadrage à gauche des libellés de colonnes, plus agréable visuellement. Ce que me permettrait facilement un composant comme le StyledCellLabelProvider, augmenté de cette faculté d'alignement.

L'implémentation aurait été facile dans dans un code source à moi, puisque le rendu du texte est réalisé dans le StyledCellLabelProvider par un TextLayout.

Seulement la variable de classe TextLayout étant privée, il me fallait soit dupliquer le code (je le déplore, préférant toujours surcharger), soit éventuellement builder ma propre version de jface, ce que je n'aime pas trop en général, m'imposant un suivi beaucoup trop minutieux lors des upgrades.

Problème, le StyledCellLabelProvider utilise une classe indispensable, ViewerCell, dont l'instance ne doit pas être remplacée au cours du traitement, et qui de surcroît à un constructeur "package", donc ni cette classe, ni une extension de cette classe, ne pouvait être instanciée hors du package. Et la méthode de construction de l'instance appelait une méthode protected d'une des classes du package.

Donc ma classe devait faire partie du même package que la classe de JFACE, afin de bénéficier des mêmes visibilités de classes et méthodes. Seulement, si faire dans mon plugin un package de même nom que celui de JFACE (org.eclipse.jface.viewers) était facile, je me doutais qu'à l'éxécution, les protections d'accès aux méthodes controllées par les classloader] et security manager de OSGI empêcherait l'exécution du code.

Je suis donc parti sur la création d'un fragment, avec le package org.eclipse.jface.viewers, contenant une classe copiée depuis StyledCellLabelProvider (j'ai fait une abstraction pour éviter qu'elle soit utilisée directement sans être étendue). Ma classe finale, étendant donc cette classe au lieu de celle de jface, étant présente dans un plugin dépendant du plugin org.eclipse.ui (lui même dépendant du plugin org.eclipse.jface).

Cela fonctionnait bien sous Eclipse, mais la build réalisée sur un serveur de build plantait en m'indiquant que la classe n'était pas accessible à cause des restrictions d'accès.

Après diverses recherches sur le web, ce problème est apparu comme un problème connu, inscrit comme bug dans le bugtracker d'Eclipse, délivré dans la release en 4.3 Milestone 7. La solution proposée étant assez similaire à la mienne, j'ai continué sur mon workaround.

Après divers recherches et essais, ne parvenant pas faire fonctionner ma build, j'ai posé la question sur ce forum, et, comme vous avez pu le voir ci-dessus, @Mickael_Istria m'a suggéré de faire un plugin plutôt qu'un fragment, et de faire une classe intermédiaire dans un package à moi, hors packages JFACE donc. Cette solution au final ne fonctionnait pas non plus, à l'exécution dans Eclipse, à cause de la restriction d'accès aux classes de JFACE (mon package avait beau avoir le même nom, ce n'était pas le même plugin).

La solution finale était donc un mélange des deux.

Objectifs

Cette solution indique :

- comment écrire une classe nécessitant d'accèder à des classes de jface de visibilité limitée(protected ou "package"), ou à invoquer des méthodes de visibilité limitée (protected ou "package") de ces classes (cette solution est applicable dans tout autre cas similaire)
- comment utiliser cette classe dans un plugin personnel, dépendant directement ou indirectement de org.eclipse.jface

La solution

J'ai créé donc un fragment dont le plugin hôte est org.eclipse.jface, lui ai donné le nom fr.wedia.util.fragments.jface, et dont voici le manifest :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
Manifest-Version: 1.0
Bundle-ManifestVersion: 2
Bundle-Name: Classes to extend/workaround Jface
Bundle-SymbolicName: fr.wedia.util.fragments.jface;singleton:=true
Bundle-Version: 1.0.0.qualifier
Fragment-Host: org.eclipse.jface
Bundle-RequiredExecutionEnvironment: J2SE-1.5
Bundle-Vendor: Wedia
Bundle-ClassPath: .
Export-Package: fr.wedia.util.jface

avec 2 classes :

• fr.wedia.util.jface.StyledCellLabelProvider StyledCellLabelProvider.java
• org.eclipse.jface.viewers.AbstractStyledCellLabelProvider AbstractStyledCellLabelProvider.java

J'ai ajouté ce fragment à la feature contenant le plugin ou se trouve ma classe destinée au composant "corbeille", classe étendant fr.wedia.util.jface.StyledCellLabelProvider. Pour ne pas avoir d'erreur dans les éditeurs d'Eclipse, j'ai dû ajouter au classpath de mon plugin :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

<classpathentry combineaccessrules="false" kind="src" path="/fr.wedia.util.fragments.jface"/>

(le nom de mon projet étant l'identifiant de mon fragment)

Je met qu'un extrait de la classe finale d'implémentation, le reste n'étant pas pertinent :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
...
import fr.wedia.util.jface.StyledCellLabelProvider;
...
 
public class ViewItemStyledCellLabelProvider extends StyledCellLabelProvider implements IViewItemCellLabelProvider {
 
    ...
 
    public ViewItemStyledCellLabelProvider(ColumnDescriptor columnDescriptor) { 
        super(columnDescriptor!=null?columnDescriptor.getAlignment().getSWTStyle():SWT.NONE);
        if ( columnDescriptor!=null ) {
            setForceLeftAlignmentIfWider(columnDescriptor.isForceLeftAlignmentIfWider(); 
        }
        this.columnDescriptor=columnDescriptor;
    } 
 
  ...

[Gueritarish]

Salut,

Sacré pavé
Beau résumé en tout cas avec toute la démarche.
Une seule remarque... Je pense que tu as dû mettre le MANIFEST de ton bundle intermédiaire (celui que Mickael t'as conseillé de créer). Plusieurs indice à ça: le Bundle-ActivationPolicy et le Bundle-Activator.
Du coup, il manque le Fragment-Host dans celui que tu as posté. Même si, ici, il est évident, ça peut être perturbant pour ceux qui reprendrait ta solution et qui comparerait leur MANIFEST au tien...
Merci pour le retour complet en tout cas.

Voilà, à+
Gueritarish

[joel.drigo]

Salut,

Sacré pavé

Oui, j'en suis conscient Et il était beaucoup plus long au début, j'ai dû le remanier, faire des coupes tout ça,

Beau résumé en tout cas avec toute la démarche.
Une seule remarque... Je pense que tu as dû mettre le MANIFEST de ton bundle intermédiaire (celui que Mickael t'as conseillé de créer). Plusieurs indice à ça: le Bundle-ActivationPolicy et le Bundle-Activator.
Du coup, il manque le Fragment-Host dans celui que tu as posté. Même si, ici, il est évident, ça peut être perturbant pour ceux qui reprendrait ta solution et qui comparerait leur MANIFEST au tien...

Merci de la remarque !!! C'est une erreur de ma part ! Comme j'ai fait des essais avec un plugin et un fragment, je me suis planté en postant le MANIFEST : j'ai mis celui du plugin au lieu du fragment.
Je corrige ça dès que j'arrive au bureau.