Mozna by tohle Sun udelal v dobe kdy nad StarOffice de fakto zlomil hul. Ale dnes, kdyz je OpenOffice v pozici druheho nejpopularnejsiho kancelarskeho baliku se sveho vlivu nevzda (resp. dost by me prekvapilo kdyby ano).
Navic mam dojem ze prvni vec kterou by vyvojari zcela svobodneho OpenOffice.org udelali, je -- PRYC S NENAŽRANOU JAVOU !! :-) - A to by se Sunu jiste take moc nelibilo.
Kdyby nahradili Javu nějakou použitelnou knihovnou, docela by se mi to líbilo, protože bych nemusel řešit problémy typu: nejde zvuk, nejde video. Teď OOo vyžaduje instalaci nejen Javy, ale i JMF (Java Media Framework či co) - a to mi jede pouze pod Sun Javou (Blackdown si neškrtne).
mno blackdown uz je nejakou dobu ze hry. Odstranovani javy je jen hloupoucky demagogismus. Proc nepouzit co je. gcj cestou taky neni, protoze toho umi relativne malo. Horko tezko snasim ruzne verze perlu na ruznych unixech - jsem rad, ze sun udrzuje javu pevne(rozdily jsou nepoznatelne), bez ruznych forku.
OOo se bez Javy obejde davno! Tohle je strašně zakořeněná pověra, že SUN drží vývoj OOo aby tak vecpal Javu na desktop uživatelů. Možná by chtěl, ale už má dávno smůlu.
Buď:
- Java kod v OOo jde plne zkompilovat pomoci GCJ (doporučuji
GCC 4.0 a vyšší) - poděkujte neunavné práci Caolan McNamary
placeného RedHatem
- ./congure --without-java ale to přijdete o kus funkčnosti
(wizardi, hsqldb engine)
Např. Fedora obsahuje verzi OOo přeloženou GCJ už dávno (FC4? zcela jistě FC5)
Většina vývojářů je stále placená SUNem, stačí se podívat na emailové adresy, takže jistou zdrženlivot chápu.
Ještě bych dodal, že díky uvolnění OOo pod licencí GPL (souběžně se SUNovskou licencí) je možný na SUNu nezávislý vývoj a to už se děje. Forků OOo už existuje několik. Moc se o nich neví a používají se spíše v Asii než v Evropě. Pro SUN je to těžká doba. Když nepovolí, dříve či později vznikne na základě GPL kódu OOo nová verze OOo, nad kterou nebude mít kontrolu. Když povolí, pak ztratí kontrolu přímo nad OOo. Je ale otázkou, komu to prospěje. Cítím za tím víc tahanici velkých firem než skutečný zájem uživatelů. Jako odpověď na routoucí závislost na OOo na Javě by přece mohl stačit GCJ.
Nemusí jít hned o fork. Existuje i ohleduplnější řešení - patchsety.
Když se patch osvědčím upstreamuje se.
Je to podobné jak s Linux jádrem. Máte Vanillu a k ní si distribuce i jednotlivci mohou přidat jeden nebo více patchů/patchsetů, podle toho co chtějí zlepšit, změnit (supermount, swsusp2, realtime patche etc.)
U jádra je bohatý výběr patchsetů, u OOo vím jen o jednom, zato pořádném - ooo-build, alias go-ooo. Distribuce začínají využívat stále více tento patchset, průkopníkem je Fedora a Novell, oba se na vývoji 'go-ooo' podílejí.
go-ooo řeší věci jako:
- nezávislos ta Javě
- kompilace na GCC 4.0, GCJ
- integraci Cairo a Glitz
- lepší spellchecker (hunspell)
- iconswitching
- hlubší integrace KDE a Gnome
- podpora VBA, Access databazí
- větší integrace systémovách knihoven
(fontconfig, stl, freetype, icu, mozilla)
- optimalizace etc.
Problém je že SUN drží pod palcem projektové CVS a IssueZillu, a nezávislí vývojáři si stěžují, že přijímá upstream patche pomalu a konzervativně, že CVS je pomalé, vytvoření CVS účtu trvá věky atd.
mno to je pekne, ale ja tohoto casu musim delat pod wokny - jsem tam velmi rad za tu javu, protoze je mozne drzet vyvoj jakztakz pohromade. Silne forky pro ruzne systemy budou znamenat konec. Co se tyka pomaleho upstreamu do CVS . Jste legracni - vite jak je obtizne dostat, byt velmi kvalitni, kod do linuxuve vetve? Uvedomte si, ze planovani projektu obsahuje i pomerne nelibive kroky, kdy se ne kazdemu vyhovi. Sun se chova jeste pomerne malo restriktivne ve srovnani lidi okolo kernel.org....
