Lavoricchiando sul OpenJUMP per DebianGis, ho scoperto che 1.3 dipende
allegramente da codice preso dalla Java Advanced Imaging Library per
implementare TIFF e suppongo GeoTIFF. Una libreria notoriamente non
libera. Do poi uno sguardo a Degree e scopro che chiaramente ha lo stesso
problema, oltre alla presenza di codice di ignota origine. GvSIG ha
problemi similari.
La domanda nasce spontanea: perche' il mondo javaro
ha la curiosa abitudine di lavorare in questo modo - come dire - allegro?
Perche' la piu' tipica distribuzione di codice java spara dozilioni
di jar blob senza curarsi affatto di definire parimenti compatibilita',
script di building e quanto altro permette - a chi volesse/dovesse ricostruire
from scratch il software - di lavorare senza arrampicarsi sugli specchi?
Chesso'... un build script per ant che funzioni, magari?
Perchè si scopre fin troppo spesso che non si riesce a compilare una
fava perchè mancano pezzi e non si sa che versioni sono state utilizzate ?
Perchè non se ne vanno afanjava tutti quanti? La tentazione di droppare
qualsiasi supporto java GIS e' forte.
Tanto per aggiungere qualcosa.
Ma lo sapevate che c'e' la tendenza, ultimamente, di usare Java
anche per fare il build di cose che di Java non avrebbero bisogno
a runtime ?
Sapevatelo!
Esempio: il geoexplorer di opengeo suite, per "compilare" javascript
(ovvero semplicemente togliere i commenti, gli accapi, gli spazi, e
mettere assieme piu' file) usa una builder implementato in _javascript_ (!!!)
che viene fatto interpretare ad un interpreter _javascript_ scritto in _java_ (!!!!)
Perche' tanto odio ?
--strk;
On Thu, Apr 15, 2010 at 08:58:11PM +0200, Francesco P. Lovergine wrote:
Lavoricchiando sul OpenJUMP per DebianGis, ho scoperto che 1.3 dipende
allegramente da codice preso dalla Java Advanced Imaging Library per
implementare TIFF e suppongo GeoTIFF. Una libreria notoriamente non
libera. Do poi uno sguardo a Degree e scopro che chiaramente ha lo stesso
problema, oltre alla presenza di codice di ignota origine. GvSIG ha
problemi similari.
La domanda nasce spontanea: perche' il mondo javaro
ha la curiosa abitudine di lavorare in questo modo - come dire - allegro?
Perche' la piu' tipica distribuzione di codice java spara dozilioni
di jar blob senza curarsi affatto di definire parimenti compatibilita',
script di building e quanto altro permette - a chi volesse/dovesse ricostruire
from scratch il software - di lavorare senza arrampicarsi sugli specchi?
Chesso'... un build script per ant che funzioni, magari?
Perchè si scopre fin troppo spesso che non si riesce a compilare una
fava perchè mancano pezzi e non si sa che versioni sono state utilizzate ?
Perchè non se ne vanno afanjava tutti quanti? La tentazione di droppare
qualsiasi supporto java GIS e' forte.
Perplesso e lievissimamente incazzato.
--
Francesco P. Lovergine
_______________________________________________
Iscriviti all'associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione
Gfoss@faunalia.it http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss
Questa e' una lista di discussione pubblica aperta a tutti.
I messaggi di questa lista non rispecchiano necessariamente
le posizioni dell'Associazione GFOSS.it.
440 iscritti al 15.3.2010
On Thu, Apr 15, 2010 at 08:58:11PM +0200, Francesco P. Lovergine wrote:
implementare TIFF e suppongo GeoTIFF. Una libreria notoriamente non
libera. Do poi uno sguardo a Degree e scopro che chiaramente ha lo stesso
problema, oltre alla presenza di codice di ignota origine. GvSIG ha
problemi similari.
Mi chiedo: ma come fanno allora i vari progetti java ad essere inclusi in osgeo? La
code review c'e' stata, no?
Siamo certi che usando uno di questi sw stiamo usando tutto e solo software libero?
Qualcuno ha seguito la cosa?
No flame please, solo per capire.
Saluti.
--
Paolo Cavallini: http://www.faunalia.it/pc
La domanda nasce spontanea: perche' il mondo javaro
ha la curiosa abitudine di lavorare in questo modo - come dire - allegro?
non è una questione di linguaggio, ho trovato ottimi software scritti
in java con builder ben fatti così come pessimi software scritti in c
impossibili da compilare oppure moduli python impossibili da far
funzionare. come sempre non è il linguaggio ma il programmatore.
riguardo l'uso di codice non OS, ce da dire che il discorso licenaze è
sempre molto complesso e spesso alcuni programmatori sbagliano in
buona fede (teniamo presente che nemmeno alcune licenze OS sono
compatibili tra loro ...).
direi che la cosa migliore da fare è evitare guerre di religione sui
linguaggi e semplicemente segnalare ai programmatori il problema.
On Fri, Apr 16, 2010 at 10:06:06AM +0200, Paolo Cavallini wrote:
Mi chiedo: ma come fanno allora i vari progetti java ad essere inclusi in osgeo? La
code review c'e' stata, no?
Siamo certi che usando uno di questi sw stiamo usando tutto e solo software libero?
Qualcuno ha seguito la cosa?
No flame please, solo per capire.
Saluti.
Una roba da perderci mesi appresso. E questo e' il punto di vista di
OsGeo. Sono abbastanza certo che a sottoporre il tutto a debian-legal,
verrebbero fuori un tale numero di eccezioni da dover tagliare via
diversi moduli. A parte che personalmente non ho intenzione di
impegnarmi in una cosa del genere, con i relativi flame di contorno.
Vorra' dire che gli utenti dovranno accontentarsi di usare i file jar presi
dal sito, nei limiti in cui funzionano.
ma vorrei alcune considerazioni da chi java lo usa e ci sviluppa.
E’ vero che :
molti SW Java dedicati al GIS non funzionano “bene” (non offrono le stesse prestazioni e funzionalità) se usati con open-jdm invece della SUN JVM.
???
riguardo a segnalarlo agli sviluppatori, per esperienza diretta, proposi l’utilizzo di open jdm per la realizzazione del live-dvd di osgeo ma alcuni sviluppatori J non accettarono perchè il proprio sw non avrebbe “reso” il dovuto.
chiacchera in tempo reale con i tuoi amici liberi! usa IRC - Internet Relay Channel
> Da: Francesco P. Lovergine frankie@debian.org > Oggetto: Re: [Gfoss] Riflessione: le javate. > A: “Paolo Cavallini” cavallini@faunalia.it > Cc: gfoss@faunalia.it > Data: Venerdì 16 Aprile 2010, 10:33 > > On Fri, Apr 16, 2010 at 10:06:06AM +0200, Paolo Cavallini wrote: > > Mi chiedo: ma come fanno allora i vari progetti java ad essere inclusi in osgeo? La > > code review c’e’ stata, no? > > Siamo certi che usando uno di questi sw stiamo usando tutto e solo software libero? > > Qualcuno ha seguito la cosa? > > No flame please, solo per capire. > > Saluti. > > Esempio: > > https://wiki.deegree.org/deegreeWiki/OSGeoIncubationCodeProvenanceReviewReport > > Una roba da perderci mesi appresso. E questo e’ il punto di vista di > OsGeo. Sono abbastanza certo che a sottoporre il tutto a debian-legal, > verrebbero fuori un tale numero di eccezioni da dover tagliare via > diversi moduli. A parte che personalmente non ho intenzione di > impegnarmi in una cosa del genere, con i relativi flame di contorno. > Vorra’ dire che gli utenti dovranno accontentarsi di usare i file jar presi > dal sito, nei limiti in cui funzionano. > > – > Francesco P. Lovergine > _______________________________________________ > Iscriviti all’associazione GFOSS.it: http://www.gfoss.it/drupal/iscrizione > Gfoss@faunalia.it > http://lists.faunalia.it/cgi-bin/mailman/listinfo/gfoss > Questa e’ una lista di discussione pubblica aperta a tutti. > I messaggi di questa lista non rispecchiano necessariamente > le posizioni dell’Associazione GFOSS.it. > 440 iscritti al 15.3.2010
notoriamente Frankie non è il candidato ideale per il Nobel della Pace:
ma devo confessarvi che ho letto il suo post (decisamente politically scorrect e molto poco diplomatico) sghignazzando veramente di gusto
Sicuramente non è il caso di scatenare “guerre di religione” tra
linguaggi … viva il pluralismo, ciascuno di noi ha le proprie
legittime preferenze ed idiosincrasie, simpatie ed antipatie …
non è assolutamente questo il punto di discussione.
Tuttavia Frankie ha posto il dito su un problema serio, molto serio,
sul quale IMHO sarebbe bene che tutta la community O.S. (non solo
quella orientata al GIS) ponesse la dovuta attenzione.
Ripeto, non è un problema di linguaggio: tuttavia resta il fatto
che sicuramente è vero che nel mondo Java è abbastanza diffusa una
certa ‘leggerezza’ nel supportare ed includere pezzi di codice più o
meno proprietario e di legittimità assai dubbia sotto il profilo
delle licenze.
Giustamente, la responsabilità ricade sui singoli team di sviluppo e
non può e non deve essere imputato a Java di per se: ma resta comunque
il fatto oggettivo che questo problema è sicuramente più acuto nel
mondo Java.
A cominciare dalla radice fondamentale stessa: non mi è mai capitato di
incontrare un qualsiasi package Java che non presentasse nelle note di
installazione un’avvertenza del tipo:
“siete vivamente pregati di usare la Virtual Machine Java Hotspot di
Sun, perché altrimenti non funziona bene …”
Ma è sempre bene ricordarsi che Hotspot (ancorchè disponibile in forma
gratuita), col cavolo che è SW libero: così come sarebbe bene ricordarsi
che a seguito dei recenti cambi di proprietà Sun è finita niente meno che
sotto il diretto controllo di Oracle.
Insomma: praticamente tutti i packages O.S. basati su Java in ultima analisi
funzionano essenzialmente per gentile concessione di Oracle.
Che può eventualmente decidere di chiudere il rubinetto in qualsiasi momento,
a proprio indiscriminato arbitrio.
forse sarebbe il caso di fare una piccola riflessione in materia
quanto meno si imporrebbe una rigorosa (auto-)certificazione che verifichi se
effettivamente ciascun singolo package Java è in grado di funzionare “a regola
d’arte” su Open JVM … perchè altrimenti si costruisce su terreni franosi !!!
Almeno queste persone: http://wiki.osgeo.org/wiki/IncCom_Meeting13
"Attending:
Frank Warmerdam (chair), Paul Spencer, Judit Mays, Markus Schneider,
Howard Butler, Steve Lime, Jeroen Ticheler, Steffen Thomas (guest),
Alexander Padberg (guest), Chip Mefford (guest), Jens Fitzke (guest),
Herman Assink (guest)
...
* Extensive discussion of deegree incubation status. Some concerns
around the role of the TMC but generally supportive. Plan for the
incubation committee members to dig into documents, hopefully leading
to a motion to graduate within the next few weeks.
"
NB:
Il gruppo "Incubator" cerca urgentemente mentors - OSGeo è formata
dalla community... ho partecipato per 1-2 anni ma i miei altri impegni
attualmente non lo permettono più.
