Bonjour,
voila, j'aimerais rajouter une fonctionnalité a un logiciel java genre LIVE Update, windows update, et Cie.
 
Je pense que tout ce qu'il y aura a checker sur le poste client est contenu dans un seul est unique jar.
 
Je pensais checker mon jar, comparer les fichiers contenus avec les fichiers de la dernière version sur un serveur distant, et mettre a jour mon jar en fonction des différences.
 
Est-ce la bonne solution? Peut-on modifier le jar de l'application alors qu'elle est deja lancée?(si oui les modifications seront prisent en compte lors du prochain demarrage de l'appli?)
 
Ou existe t'il des moyen plus facile ?(api et Cie)

Java webstart.
 
Le principe : tu décris dans un fichier xml les paramètres et les jars nécessaires au lancement de ton application.  
 
A chaque lancement webstart vérifie qu'il n'y a eu de modifications du fichier xml et le cas échéant charge les nouveaux jars.
 
Marche bien. J'ai une appli qui utilise ça et que tu peux tester sur http://eap.bug-sweeper.fr/

 
 
Avec une appli autonome je vais pouvoir m'en sortir?

Oui. Le principe est de versionner tes jars et de lui dire où ils se trouvent.
 
Par exemple pour mon appli :
 

 
Ensuite si tu as besoin de mettre à jour ton appli tu génère un nouveau jar avec le numéro suivant et tu change ton fichier jnlp en conséquence.

replix > interessante ton appli ...
t'aurais pas un peu pompé certaines icons (le status) et "concept" (le style des clés d'issues TRUC-145) de jira des fois?

Mea culpa sur les icones...   . Si je vais plus loin, je ferai faire des icônes sur mesures. Pour l'instant, il ne s'agissait que de tester.
 
Pour le concept, je me suis basé sur plusieurs produits existants, sachant que les principes sont très proches d'une appli à l'autre...

vu que ton appli coté serveur est web, ça aurait été chouette que ton appli cliente permette d'utiliser jira comme backend (ils ont une interface xml-rpc ou soap)

En fait l'idée est de fournir un service en mode hébergée et loué mensuellement => je gère le client et le serveur.
 
De plus, je ne suis pas un grand fan de SOAP sur le concept. Pour l'avoir pratiqué en prod je trouve que c'est assez lourd.
 
Mon appli utilise une communication binaire encapsulée dans des flux HTTP. Cela me permet d'être beaucoup plus performant et très productif sur mes développements en ne me préoccupant pas du tout de la couche de communication.

ha oui, j'ai vu le lien sur le site vers la lib qui gère ta couche de comm.; interessant, je connaissais pas mais ça "ferme" un peu le truc non? ou bien est-ce que ça permet aussi d'exposer le service comme soap ou xml-rpc le permettent?

Je pourrai toujours décider d'ouvrir le service en proposant des interfaces SOAP ou XML-RPC.
 
Après c'est de la stratégie de développement.

et donc ça t'interessait pas de fournir un client pour jira plutot que de tout refaire... ? juste à cause du protocole ou bien par défi, ou bien tu as des idées differentes de jira? (au niveau modèle, back-end etc, manifestement le front end est different )

C'est un projet de business. Si je fais un client pour Jira, il faut que je me mette d'accord avec eux, ...
 
D'autre part, mon idée est de fournir un service de gestion de projets informatiques (dont gestion de bugs) en ligne et non une licence et un produit à installer en local.

ils engagent
et ptet qu'ils seraient interessés de te fournir une license pour tes services
enfin je demande ça par pure curiosité quoi; ici on utilise jira et on en est très content, au poins qu'on l'utilise déjà (et pê bientot encore plus) en dehors du secteur du developement it; donc forcément l'integration avec d'autres produits est un facteur important.
 
(de même que qd tu achetes n'importe quel front end tu t'assures que c compatible avec ta db existente etc...)
 
- encore une fois, c'est juste de la curiosité, pas des critiques