PerdonamiOriginariamente inviata da andbin
ma riesci spiegarmi + o - come aggiungere questo attributo Class-Path....scusami sono proprio ancora poco capace con java
Perdonami
Nel manifest dovrai avere una riga del tipo:Perdonami
Class-Path: libs/itextpdf-X.Y.Z.jar
Ovviamente puoi rinominare il jar togliendo la versione (sconsigliato comunque) o cambiare il path.
Se usi libs/ vuol solo poi dire che nella (qualunque) directory dove hai ProgettoJava.jar, dovrai avere questa libs con dentro il jar.
Ah, so che di iText quello non è l'unico jar, ce n'è uno per il "pdfa" e uno di "xtra", verifica se ti servono oppure no. Più path nell'attributo Class-Path vanno separati semplicemente con spazio (e occhio alla limitazione "pignola" dei 72 caratteri per riga).
Andrea, andbin.dev – Senior Java developer – SCJP 5 (91%) • SCWCD 5 (94%)
java.util.function Interfaces Cheat Sheet — Java Versions Cheat Sheet
ciao so chi odierai ma quando ho aperto il manifest dentro ho visto che c'erano già degli attributi classPath e mi sembrano ci siano quelli che tu mi suggerisci di aggiungere...mi sbaglio??
ti prego non mi odiarecodice:Manifest-Version: 1.0 Ant-Version: Apache Ant 1.8.4 Created-By: 1.7.0_45-b18 (Oracle Corporation) Class-Path: lib/itext-pdfa-5.4.4-javadoc.jar lib/itext-pdfa-5.4.4-sour ces.jar lib/itext-pdfa-5.4.4.jar lib/itext-xtra-5.4.4-javadoc.jar lib /itext-xtra-5.4.4-sources.jar lib/itext-xtra-5.4.4.jar lib/itextpdf-5 .4.4-javadoc.jar lib/itextpdf-5.4.4-sources.jar lib/itextpdf-5.4.4.ja r X-COMMENT: Main-Class will be added automatically by build Main-Class: Archivio.ArchivioMain
non ti ho detto che tutto il lavoro lo svolto con netBeans e che quando creo il jar nella cartella dist che mi crea con all interno il jar mi crea anche una cartella lib con dentro tutti i jar che poi sono elencati nel manifest non so se ti serva ma te lo dico lo stesso
Ultima modifica di kekkuz87; 02-01-2014 a 17:23
Innanzitutto i jar dei javadoc/sources sono totalmente inutili ai fini di far girare l'applicazione. Quindi non servono.
Supponendo che nel Class-Path ci siano solo i jar davvero necessari, il contenuto della dist è quello che dovrai "portare in giro" ogni volta, così come è, con quella struttura.
Andrea, andbin.dev – Senior Java developer – SCJP 5 (91%) • SCWCD 5 (94%)
java.util.function Interfaces Cheat Sheet — Java Versions Cheat Sheet
ok quindi semplicemente non posso usare solo il file jar ma devo "portare in giro" tutta la cartella dist...ok e ma non esisterebbe un modo per poter portare in giro solo il file jar??
PS se è troppo complicato mi accontento di questo
PPS ma il "problema" si pone ogni volta che utilizzerò una libreria esterna
Ultima modifica di kekkuz87; 02-01-2014 a 17:37
Premessa: alla JVM alla fin fine non interessa sapere se ci sono 2, 3, 4 ... jar ... alla JVM basta che le classi/risorse siano rintracciabili per cui dato un nome completamente "qualificato", i nomi di package si "riflettono" in nomi di cartelle e il percorso viene cercato lungo il classpath.
Quindi tecnicamente basterebbe avere un unico jar che contiene tutti i package e le classi/risorse necessarie. Il punto è che o lo fai tu a mano o con un tuo scriptino (non è difficile ma è da fare facendo un po' di attenzione per evitare di perdere/sballare la struttura) oppure lo fa l'IDE. Con Eclipse mi pare ci sia un plugin (non l'ho mai usato, onestamente ...) per un "Fat jar". Con NetBeans non ho idea ...
Le problematiche dell'avere un unico jar però sono almeno 3:
1) Questioni di "licenza", l'autore della libreria potrebbe non gradire questo.
2) Questioni di aggiornamento. Se i jar fossero "sciolti" e senza versione, solo es. itextpdf.jar, potresti aggiornare un singolo jar con un'altra versione facilmente.
3) Perdi la informazione "a vista" di quali jar/versioni hai delle librerie.
Sì, in generale è sempre così.
Andrea, andbin.dev – Senior Java developer – SCJP 5 (91%) • SCWCD 5 (94%)
java.util.function Interfaces Cheat Sheet — Java Versions Cheat Sheet
Non sempre è possibile ed è fortemente scoraggiato farlo anche quando è "tecnicamente" possibile. Per diverse, validissime, ragioni:
1) Le librerie sono, appunto, librerie: non sono software tuo, non le sviluppi tu e quindi non è concettualmente corretto che vengano incorporate nel tuo software
2) Le librerie sono soggette ad aggiornamenti: se fossero tutte contenute nel tuo JAR, l'aggiornamento sarebbe impossibile (o, quantomeno, molto oneroso: dovresti spacchettare tutto, aggiornare e re-impacchettare tutto)
3) Alcune librerie sono "sealed": sono, cioè, impacchettate in un jar con un determinato nome e non possono funzionare se non dentro a quel particolare jar; queste non possono essere incorporate.
4) Alcuni produttori di libreria vietano questa pratica, per ovvie ragioni.
Più che "complicato" è "controproducente". Conviene sempre tenerle separate e distribuirle "al di fuori" del JAR... la fatica è la stessa: fai un file ZIP con dentro il JAR e la directory "lib"... fatto.PS se è troppo complicato mi accontento di questo
Ovviamente sì.PPS ma il "problema" si pone ogni volta che utilizzerò una libreria esterna
Ciao.
"Perchè spendere anche solo 5 dollari per un S.O., quando posso averne uno gratis e spendere quei 5 dollari per 5 bottiglie di birra?" [Jon "maddog" Hall]
Fatti non foste a viver come bruti, ma per seguir virtute e canoscenza
grazie mille per le risposte siete utilissimi come al solito...in effetti avete ragione non avevo pensato al fatto che se sono librerie di qualcun altro magari chi le ha create non è contentissimo se le incorporo nel mio softwate
Un ultima cosa poi non disturbo +quando all'inizio del post mi avete suggerito di indicare in fase di serializzazione e deserializzazione il percorso di salvataggio come faccio ad indicare che mi salvi l'archivio ad esempio sul desktop sia nel caso che usi windows che ubuntu (nel senso come faccio che non vi siano conflitti rispetto all sistema operativo che sto usando in un certo momento)??
PS grazie ancora per l'aiuto siete mitici
Permessi di invio
Rispondi quotando
