On Tue, 2008-10-14 at 20:54 +0300, Muayyad AlSadi wrote: > > a) what happens when you run file->wizards->letter ? ... > > c) what happens when you use tools->xml filter settings-> and add a new > > xslt transform and use "test xslts" ... > > > > Those examples need java to work, whether go-ooo.org or vanilla. > > > regarding a, c in go-oo 2.4.x they just say "please install jre > package" see attachement There's no magic go-ooo pixie dust there, that's a vanilla dialog shown when no jvm/java-infrastructure at all is found when trying to trigger java-dependant functionality. The OOo of that screen-shot hasn't found a jvm at all. If there *was* a jvm, the next stage would be to find out that the next set of requirements is missing, at which point something generally will fail silently. i.e. that dialog says "no java was found", if there *was* a java but not e.g. lucene/saxon it will say nothing and just not work. That's a miserable user experience, and people will in their thousands get into that situation and not be able to get out it. > and b,d they are not included in the livecd they are in a separated > package, anyway who needs ooo-base in a livecd, fedora livecd don't > ship any replacement ooo-base. Sure, and dropping oobase from a LiveCD is reasonable, so the hsqldb requires in F-10 is now just on oobase, rather than core. My point there was that go.ooo is no different from vanilla in needing java to work correctly, and moving to go.ooo gains you very little in terms of a java-less OOo. Not "Require:"ing the Java requirements for help and other always presented dialogs and menus that are shown as available is to fudge the reality that OOo truly does require those packages for Ooo to fulfil the contract that the UI makes with the user. Taking "removing java from core dependencies" as the target, then the right approach is the boring slow-fix stuff to e.g. rewrite the help search to not require the java lucene stuff and to tweak the xsltfilter stuff to be a standalone expert-style feature that only appears in the menus when the xsltfilter package is installed and place the saxon requires on that subpackage, and so on for other java functionality. Or not do any of that, and investigate further as to why exactly removing or replacing java dependencies is the target, when I last thought seriously about the area I felt the right thing to do was stop swimming against the tide and boil out some concrete standalone feature requires for gcj to be able to provide the functionality that was missing at that stage to implement the java-needs of OOo, and our fabulous java hackers simply implemented them. Your questions should be what exactly are the size figures are for requiring the java dependencies and where is that space getting used and why. > I'm not asking to make the striped openoffice the default, I'm asking > to make the default behaviour in comps to be full featured, but > packages dependency should allow removal of java I think this is the wrong approach. OOo will just end up getting installed part-working an awful lot of the time and the OOo maintainer of the day will have to deal with the resulting justified bile and hatred. I'm no lover of java, and I've previously expended effort of making OOo buildable without java for platforms that don't have a working java and on replacing java functionality with native code in some time critial build-paths, so I'm all in favour of what you want to achieve, but I don't want to compromise to make it happen. C. -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
