Utilisation d'une classe d'un package dans un autre package
3 réponses
rustine22
Bonjour,
j'avais un prog en java composé de qq classes dans le package par
defaut. En cherchant sur le net, j'ai trouvé un package "client FTP"
tres pratique nommé com.cqs.ftp (j'ai les sources) .
Dans ce package, je veux modifier une classe d'affichage de
l'avancement de l'upload (StdoutSizeTransferMonitor ) du package
com.cqs.ftp, en rajoutant dans le constructeur une "réference" à une
classe graphique (ThreadGraphique) de mon prog principal (dans le
package par défaut) qui permettra d'appeler une méthode de MAJ d'une
barre d avancement..
Le problème, c'est que Eclipse me reponds :
ThreadGraphique ne peut pas être résolu (ou ne correspond pas à un
type valide) pour la zone StdoutSizeTransferMonitor.t
ou t est un champ privé de la classe StdoutSizeTransferMonitor de type
ThreadGraphique..
J'ai bien mis la classe ThreadGraphique en public pour qu'elle soit
visible par le 2eme package (com.cqs.ftp )..
J'ai ensuite tenté de mettre le prog principal dans un package (autre
que par defaut) que j'ai appelé "mainprog" et rajouté un :
import mainprog;
ou
import mainprog.*;
dans StdoutSizeTransferMonitor
mais Eclipse me dit :
L'importation mainclass ne peut pas être résolue
Je ne sais plus quoi faire.. Un probleme de CLASSPATH? (pourtant
Eclipse l'avait tres bien geré jusqu'à maintenant..)
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Orabîg
rustine22 wrote: (...)
ThreadGraphique ne peut pas être résolu (ou ne correspond pas à un type valide) pour la zone StdoutSizeTransferMonitor.t (...)
Je comprends pas bien, mais est-ce que tu es certain d'avoir déclaré le package de ThreadGraphique dans la classe qui essaye d'y accéder ? Si par exemple, cette classe ThreadGraphique est dans le package mainprog, le source de ta classe "customizée" StdoutSizeTranferMonitor doit ressembler à ça :
package com.cqs.ftp;
(...) import mainprog.*; // Permet à cette classe de "voir" la classe ThreadGraphique (...)
public class StdoutSizeTranferMonitor (...) private ThreadGraphique t = null; (...)
Si ca ne marche toujours pas, est-ce que ces deux classes sont dans le même projet sous Eclipse ? Si ce n'est pas le cas, il faut que tu ajoutes une dépendance entre les projets.
Une dernière remarque : je ne connais pas la bibliothèque com.cqs.ftp dont tu parles, mais je suis étonné que tu sois obligé de modifier ses sources pour ajouter ton propre moniteur graphique. Es-tu sur qu'il ne suffit pas de remplacer le moniteur StdoutSizeTranferMonitor par un autre à toi qui implémenterais la même interface ? Ca me semble beaucoup plus propre comme ça.
Javament
-- Benoît Chauvet
rustine22 wrote:
(...)
ThreadGraphique ne peut pas être résolu (ou ne correspond pas à un
type valide) pour la zone StdoutSizeTransferMonitor.t
(...)
Je comprends pas bien, mais est-ce que tu es certain d'avoir déclaré le
package de ThreadGraphique dans la classe qui essaye d'y accéder ?
Si par exemple, cette classe ThreadGraphique est dans le package mainprog,
le source de ta classe "customizée" StdoutSizeTranferMonitor doit ressembler
à ça :
package com.cqs.ftp;
(...)
import mainprog.*; // Permet à cette classe de "voir" la classe
ThreadGraphique
(...)
public class StdoutSizeTranferMonitor
(...)
private ThreadGraphique t = null;
(...)
Si ca ne marche toujours pas, est-ce que ces deux classes sont dans le même
projet sous Eclipse ? Si ce n'est pas le cas, il faut que tu ajoutes une
dépendance entre les projets.
Une dernière remarque : je ne connais pas la bibliothèque com.cqs.ftp dont
tu parles, mais je suis étonné que tu sois obligé de modifier ses sources
pour ajouter ton propre moniteur graphique. Es-tu sur qu'il ne suffit pas de
remplacer le moniteur StdoutSizeTranferMonitor par un autre à toi qui
implémenterais la même interface ? Ca me semble beaucoup plus propre comme
ça.
ThreadGraphique ne peut pas être résolu (ou ne correspond pas à un type valide) pour la zone StdoutSizeTransferMonitor.t (...)
Je comprends pas bien, mais est-ce que tu es certain d'avoir déclaré le package de ThreadGraphique dans la classe qui essaye d'y accéder ? Si par exemple, cette classe ThreadGraphique est dans le package mainprog, le source de ta classe "customizée" StdoutSizeTranferMonitor doit ressembler à ça :
package com.cqs.ftp;
(...) import mainprog.*; // Permet à cette classe de "voir" la classe ThreadGraphique (...)
public class StdoutSizeTranferMonitor (...) private ThreadGraphique t = null; (...)
Si ca ne marche toujours pas, est-ce que ces deux classes sont dans le même projet sous Eclipse ? Si ce n'est pas le cas, il faut que tu ajoutes une dépendance entre les projets.
Une dernière remarque : je ne connais pas la bibliothèque com.cqs.ftp dont tu parles, mais je suis étonné que tu sois obligé de modifier ses sources pour ajouter ton propre moniteur graphique. Es-tu sur qu'il ne suffit pas de remplacer le moniteur StdoutSizeTranferMonitor par un autre à toi qui implémenterais la même interface ? Ca me semble beaucoup plus propre comme ça.
Javament
-- Benoît Chauvet
rustine22
Bonsoir,
merci pour ta réponse, j'ai en fait redéfini le classpath correctement (cad dans les proprietés avancées du poste de travail) et surtout redemarré Eclipse!
Et la miracle, Eclipse a bien accepté la ligne
import mainprog.*;
Sinon concernant ta dernière question :
La classe d'affichage dont je parle StdoutSizeTransferMonitor porte bien son nom car elle affiche sur la sortie standard, l'avancement en bytes .. mais elle dérive d'une classe comportant des méthodes virtuelles faite exprès pour visualiser les transferts : TransferMonitor
Par paresse, j'ai réecrit StdoutSizeTransferMonitor alors que j'aurais du en ecrire une autre derivant de TransferMonitor comme FrameTransferMonitor..
A+ Marc
"Orabîg" wrote in message news:<bp7b1k$1qe$...
rustine22 wrote: (...)
ThreadGraphique ne peut pas être résolu (ou ne correspond pas à un type valide) pour la zone StdoutSizeTransferMonitor.t (...)
Je comprends pas bien, mais est-ce que tu es certain d'avoir déclaré le package de ThreadGraphique dans la classe qui essaye d'y accéder ? Si par exemple, cette classe ThreadGraphique est dans le package mainprog, le source de ta classe "customizée" StdoutSizeTranferMonitor doit ressembler à ça :
package com.cqs.ftp;
(...) import mainprog.*; // Permet à cette classe de "voir" la classe ThreadGraphique (...)
public class StdoutSizeTranferMonitor (...) private ThreadGraphique t = null; (...)
Si ca ne marche toujours pas, est-ce que ces deux classes sont dans le même projet sous Eclipse ? Si ce n'est pas le cas, il faut que tu ajoutes une dépendance entre les projets.
Une dernière remarque : je ne connais pas la bibliothèque com.cqs.ftp dont tu parles, mais je suis étonné que tu sois obligé de modifier ses sources pour ajouter ton propre moniteur graphique. Es-tu sur qu'il ne suffit pas de remplacer le moniteur StdoutSizeTranferMonitor par un autre à toi qui implémenterais la même interface ? Ca me semble beaucoup plus propre comme ça.
Javament
Bonsoir,
merci pour ta réponse, j'ai en fait redéfini le classpath correctement
(cad dans les proprietés avancées du poste de travail) et surtout
redemarré Eclipse!
Et la miracle, Eclipse a bien accepté la ligne
import mainprog.*;
Sinon concernant ta dernière question :
La classe d'affichage dont je parle StdoutSizeTransferMonitor porte
bien son nom car elle affiche sur la sortie standard, l'avancement en
bytes .. mais elle dérive d'une classe comportant des méthodes
virtuelles faite exprès pour visualiser les transferts :
TransferMonitor
Par paresse, j'ai réecrit StdoutSizeTransferMonitor alors que j'aurais
du en ecrire une autre derivant de TransferMonitor comme
FrameTransferMonitor..
A+
Marc
"Orabîg" <benoit@chauvet.com> wrote in message news:<bp7b1k$1qe$1@news.tiscali.fr>...
rustine22 wrote:
(...)
ThreadGraphique ne peut pas être résolu (ou ne correspond pas à un
type valide) pour la zone StdoutSizeTransferMonitor.t
(...)
Je comprends pas bien, mais est-ce que tu es certain d'avoir déclaré le
package de ThreadGraphique dans la classe qui essaye d'y accéder ?
Si par exemple, cette classe ThreadGraphique est dans le package mainprog,
le source de ta classe "customizée" StdoutSizeTranferMonitor doit ressembler
à ça :
package com.cqs.ftp;
(...)
import mainprog.*; // Permet à cette classe de "voir" la classe
ThreadGraphique
(...)
public class StdoutSizeTranferMonitor
(...)
private ThreadGraphique t = null;
(...)
Si ca ne marche toujours pas, est-ce que ces deux classes sont dans le même
projet sous Eclipse ? Si ce n'est pas le cas, il faut que tu ajoutes une
dépendance entre les projets.
Une dernière remarque : je ne connais pas la bibliothèque com.cqs.ftp dont
tu parles, mais je suis étonné que tu sois obligé de modifier ses sources
pour ajouter ton propre moniteur graphique. Es-tu sur qu'il ne suffit pas de
remplacer le moniteur StdoutSizeTranferMonitor par un autre à toi qui
implémenterais la même interface ? Ca me semble beaucoup plus propre comme
ça.
merci pour ta réponse, j'ai en fait redéfini le classpath correctement (cad dans les proprietés avancées du poste de travail) et surtout redemarré Eclipse!
Et la miracle, Eclipse a bien accepté la ligne
import mainprog.*;
Sinon concernant ta dernière question :
La classe d'affichage dont je parle StdoutSizeTransferMonitor porte bien son nom car elle affiche sur la sortie standard, l'avancement en bytes .. mais elle dérive d'une classe comportant des méthodes virtuelles faite exprès pour visualiser les transferts : TransferMonitor
Par paresse, j'ai réecrit StdoutSizeTransferMonitor alors que j'aurais du en ecrire une autre derivant de TransferMonitor comme FrameTransferMonitor..
A+ Marc
"Orabîg" wrote in message news:<bp7b1k$1qe$...
rustine22 wrote: (...)
ThreadGraphique ne peut pas être résolu (ou ne correspond pas à un type valide) pour la zone StdoutSizeTransferMonitor.t (...)
Je comprends pas bien, mais est-ce que tu es certain d'avoir déclaré le package de ThreadGraphique dans la classe qui essaye d'y accéder ? Si par exemple, cette classe ThreadGraphique est dans le package mainprog, le source de ta classe "customizée" StdoutSizeTranferMonitor doit ressembler à ça :
package com.cqs.ftp;
(...) import mainprog.*; // Permet à cette classe de "voir" la classe ThreadGraphique (...)
public class StdoutSizeTranferMonitor (...) private ThreadGraphique t = null; (...)
Si ca ne marche toujours pas, est-ce que ces deux classes sont dans le même projet sous Eclipse ? Si ce n'est pas le cas, il faut que tu ajoutes une dépendance entre les projets.
Une dernière remarque : je ne connais pas la bibliothèque com.cqs.ftp dont tu parles, mais je suis étonné que tu sois obligé de modifier ses sources pour ajouter ton propre moniteur graphique. Es-tu sur qu'il ne suffit pas de remplacer le moniteur StdoutSizeTranferMonitor par un autre à toi qui implémenterais la même interface ? Ca me semble beaucoup plus propre comme ça.
Javament
Benoît Chauvet
rustine22 wrote:
Bonsoir,
merci pour ta réponse, j'ai en fait redéfini le classpath correctement (cad dans les proprietés avancées du poste de travail) et surtout redemarré Eclipse!
Et la miracle, Eclipse a bien accepté la ligne
En effet, Eclipse aime bien qu'on le redemarre de temps à autre (il aime bien les F5 aussi, pour rafraichir tel ou tel projet. A consommer sans modération)
Sinon concernant ta dernière question :
La classe d'affichage dont je parle StdoutSizeTransferMonitor porte bien son nom car elle affiche sur la sortie standard, l'avancement en bytes .. mais elle dérive d'une classe comportant des méthodes virtuelles faite exprès pour visualiser les transferts : TransferMonitor
Par paresse, j'ai réecrit StdoutSizeTransferMonitor alors que j'aurais du en ecrire une autre derivant de TransferMonitor comme FrameTransferMonitor..
Alors si tu es conscient du fait, tout va bien. :) De plus, si une classe abstraite existe, elle doit vraiment faire tout le boulot.
Enfin, je n'ai pas perdu ma journée, j'ai trouvé qqun d'encore plus paresseux que moi ;)
Javament
-- Benoît Chauvet
rustine22 wrote:
Bonsoir,
merci pour ta réponse, j'ai en fait redéfini le classpath correctement
(cad dans les proprietés avancées du poste de travail) et surtout
redemarré Eclipse!
Et la miracle, Eclipse a bien accepté la ligne
En effet, Eclipse aime bien qu'on le redemarre de temps à autre (il aime
bien les F5 aussi, pour rafraichir tel ou tel projet. A consommer sans
modération)
Sinon concernant ta dernière question :
La classe d'affichage dont je parle StdoutSizeTransferMonitor porte
bien son nom car elle affiche sur la sortie standard, l'avancement en
bytes .. mais elle dérive d'une classe comportant des méthodes
virtuelles faite exprès pour visualiser les transferts :
TransferMonitor
Par paresse, j'ai réecrit StdoutSizeTransferMonitor alors que j'aurais
du en ecrire une autre derivant de TransferMonitor comme
FrameTransferMonitor..
Alors si tu es conscient du fait, tout va bien. :)
De plus, si une classe abstraite existe, elle doit vraiment faire tout le
boulot.
Enfin, je n'ai pas perdu ma journée, j'ai trouvé qqun d'encore plus
paresseux que moi ;)
merci pour ta réponse, j'ai en fait redéfini le classpath correctement (cad dans les proprietés avancées du poste de travail) et surtout redemarré Eclipse!
Et la miracle, Eclipse a bien accepté la ligne
En effet, Eclipse aime bien qu'on le redemarre de temps à autre (il aime bien les F5 aussi, pour rafraichir tel ou tel projet. A consommer sans modération)
Sinon concernant ta dernière question :
La classe d'affichage dont je parle StdoutSizeTransferMonitor porte bien son nom car elle affiche sur la sortie standard, l'avancement en bytes .. mais elle dérive d'une classe comportant des méthodes virtuelles faite exprès pour visualiser les transferts : TransferMonitor
Par paresse, j'ai réecrit StdoutSizeTransferMonitor alors que j'aurais du en ecrire une autre derivant de TransferMonitor comme FrameTransferMonitor..
Alors si tu es conscient du fait, tout va bien. :) De plus, si une classe abstraite existe, elle doit vraiment faire tout le boulot.
Enfin, je n'ai pas perdu ma journée, j'ai trouvé qqun d'encore plus paresseux que moi ;)
