> Prace s knihovnamy (resp. naprosta absence funkcni koncepce knihoven) je > asi nejvetsi problem Javy jako platformy.
Naprostý souhlas, Global Assembly Cache a verzování jako základní součást platformy můžeme .NETistům jenom závidět. S tím Metrem mne to teď pěkně zarazilo. Vybral jsem si ho mimo jiné kvůli malému množství JARů a triviální instalaci -- srov. třeba s CXF --, a teď se dozvím tohle. Při vývoji jsem zatím na nic nenarazil, takže už se těším na problémy při produkčním nasazení :-( LT > > > Kamil "podlesh" Podlesak > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Jan Moravec > > Sent: Tuesday, August 19, 2008 2:22 PM > > To: 'Java' > > Subject: Monoliticke JARy (napr. Metro webservices-extra.jar) > > > > > > Zdravim, > > > > Pochopil jste nekdo proc Sun (a urcite jsem to videl i u > > jinych) distribuuje nektere sve produkty tak, ze vezme > > nekolik knihoven, ty rozbali a udela z nich jeden obrovsky > > monoliticky JAR? > > > > Priklad: Sun Metro WS stack > > > > To by se clovek opravdu strelil. Jednim z jeho runtime JARu > > je webservices-extra.jar, ktery v sobe obsahuje Java Mail, > > Java Activation, Java Annotations a kus Java Security. Bez > > tohoto JARu Metro nejede, tudiz ho pribaluji k aplikaci. Proc > > nejsou tyto dilci knihovny distribuovany jako oddelene JARy - > > standardni activation.jar, mail.jar, annotations.jar + zminka > > v Metro dokumentaci jaka verze ceho je pro beh potreba? Toto > > zpusobuje to, ze neni snadne Metro nasadit v prostredi, ktere > > jiz treba activation API a mail API poskytuje ze sveho > > runtimu (v mem pripade JBoss AS). Resim tak, ze z Metra JARu > > odmazavam prislusna API, abych se vyhnul kolizim s runtime > > knihovnami AS, coz je neudrzitelne. > > > > Toto jde preci proti konceptu spravy zavislosti, kdy je > > potreba z principu zavislosti oddelovat a ne slucovat. > > > > Asi placu na nespravnem hrobe :) Diky za pripadna osvetleni. > > Honza > > > > > > >
