pena ooo-build-2.0.0.1 # find -name "*.jar" ./build/ooo680-m3/avmedia/source/java/avmedia.jar ./build/ooo680-m3/external/common/jaxp.jar ./build/ooo680-m3/external/common/parser.jar ./build/ooo680-m3/external/common/xt.jar ./build/ooo680-m3/external/common/xt19991105.jar ./build/ooo680-m3/filter/source/jars/XFlatXml.jar ./build/ooo680-m3/filter/source/jars/XMergeBridge.jar ./build/ooo680-m3/filter/source/jars/aportisdoc.jar ./build/ooo680-m3/filter/source/jars/docbook.jar ./build/ooo680-m3/filter/source/jars/htmlsoff.jar ./build/ooo680-m3/filter/source/jars/minicalc.jar ./build/ooo680-m3/filter/source/jars/pexcel.jar ./build/ooo680-m3/filter/source/jars/pocketword.jar ./build/ooo680-m3/filter/source/jars/xmerge.jar ./build/ooo680-m3/helpcontent2/helpers/helpauthoring/filter/helpauthoring.jar ./build/ooo680-m3/netbeans_integration/jarpackager.jar ./build/ooo680-m3/netbeans_integration/jhall.jar ./build/ooo680-m3/netbeans_integration/nbantext.jar ./build/ooo680-m3/netbeans_integration/openide.jar ./build/ooo680-m3/qadevOOo/testdocs/qadevlibs/JobExecutor.jar ./build/ooo680-m3/qadevOOo/testdocs/qadevlibs/MyPersistObjectImpl.jar ./build/ooo680-m3/smoketestoo_native/statjars/jcommon-0.7.1.jar ./build/ooo680-m3/smoketestoo_native/statjars/jfreechart-0.9.4.jar ./build/ooo680-m3/xalan/download/xalan.jar ./build/ooo680-m3/xalan/download/xercesImpl.jar ./build/ooo680-m3/xalan/download/xml-apis.jar The ones that are used during the build process should use the system installed jar files instead of the packed ones. See the following guide for help in writing java ebuilds: http://www.gentoo.org/proj/en/java/java-devel.xml#doc_chap3
Hmm, did you actually take a look at the OOo build system, or have a plan how to implement this? OOo is moving upstream at using system-stuff more and more, but still uses / needs a lot of internal stuff. This sounds nice in theory, but this really is not just a matter of fixing the ebuild, also a lot of build stuff will have to be changed. Like I said moving to system stuff more and more is one of the things currently being done upstream, but nothing we can do easily now. Also a lot of the files you are referencing are actually OOo specific stuff, like help and filters.
(In reply to comment #1) > Hmm, did you actually take a look at the OOo build system, or have a plan how to > implement this? OOo is moving upstream at using system-stuff more and more, but > still uses / needs a lot of internal stuff. > Did you actually take a look at the link I gave you? http://www.gentoo.org/proj/en/java/java-devel.xml#java-pkg.eclass # java-pkg_jarfrom * Creates symlinks to the jars of a package in the cwd * Can be called with o A comma separated list of packages o A single package and the jar name you want from that package o A single package, the jar name, and the name of symlink * Will die on errors
Petteri: What is the benefit of doing this except from the warm fuzzy feeling. I know you do this with regular java apps, but openoffice is hardly a regular java app. Also some of those jars are actually removed during the build process. But my biggest questions are on the benefits. Doing this would significantly increase the complexity of the openoffice build process and ebuild (which is already brittle by itself). It would also increase the build-time dependencies of the ebuild while the package already provides everything needed.
(In reply to comment #3) > Petteri: What is the benefit of doing this except from the warm fuzzy feeling. I > know you do this with regular java apps, but openoffice is hardly a regular java > app. The normal reasons. I know that the open office build process is problematic and because of that I don't expect this to get fixed immediately, but the bug should still be here for everyone to see and try to fix if they like. http://gentooexperimental.org/svn/java/axxo-overlay/README/docs/java-devel.html#doc_chap3 > Also some of those jars are actually removed during the build process. But > my biggest questions are on the benefits. Doing this would significantly > increase the complexity of the openoffice build process and ebuild (which is > already brittle by itself). It would also increase the build-time dependencies > of the ebuild while the package already provides everything needed. Java libraries should not be any different from normal system libraries. There is openoffice-bin for those who want to use pre packed binaries. Let's hope upstream makes life easier for us in the future.
Some update. jaxp.jar and parser.jar will vanish somewhen. With ooo-build they are not used. beanshell, db's jar, hsqldb, xalan, xerces (xercesImpl & xml-apis [from xerces not to hit some errors]) and xt you can use from system now. I have useflags for them in my overlay. I personally use beanshell, db's jar, xalan, xerces (xercesImpl & xml-apis) from system. hsqldb and xt useflags are untested. You may have a look at my overlay and tell me how to solve it better, please. :) http://forums.gentoo.org/viewtopic-t-195406.html
openoffice-2.1.0 uses a lot more jars from system now, namely beanshell, xalan, xerces, xml-apis, serializer. More to come.
(In reply to comment #6) > openoffice-2.1.0 uses a lot more jars from system now, namely beanshell, xalan, > xerces, xml-apis, serializer. More to come. > Good news. As for what to come, I hope for hsqldb, although the one in portage is probably outdated? However, you shouldn't hardcode paths to system jars like you do. There's a function java-pkg_getjar (first parameter is package name or name-slot if slot != 0, second is the jar filename)to get you this path, so you do something like: echo "--with-xerces-jar=$(java-pkg_getjar xerces-2 xercesImpl.jar)" >> ${CONFFILE}
(In reply to comment #7) > > Good news. As for what to come, I hope for hsqldb, although the one in portage > is probably outdated? Yes the version in portage is to outdated to be used, we'd need >=dev-db/hsqldb-1.8.0.4 for that Also I'd like to add xt, but had problems building xp when trying it, will have to check again > However, you shouldn't hardcode paths to system jars like you do. There's a > function java-pkg_getjar (first parameter is package name or name-slot if slot > != 0, second is the jar filename)to get you this path, so you do something > like: > echo "--with-xerces-jar=$(java-pkg_getjar xerces-2 xercesImpl.jar)" >> > ${CONFFILE} Thanks will fix that (hopefully soon, depends on how many more important bugs keep popping up...)
(In reply to comment #8) > Yes the version in portage is to outdated to be used, we'd need > >=dev-db/hsqldb-1.8.0.4 for that let's depend on its bump bug then > > Also I'd like to add xt, but had problems building xp when trying it, will have > to check again Feel free to create bugs about anything you miss and block this one. > > However, you shouldn't hardcode paths to system jars like you do. There's a > > function java-pkg_getjar (first parameter is package name or name-slot if slot > Thanks will fix that (hopefully soon, depends on how many more important bugs > keep popping up...) Thanks, this is not critical so it can wait for something important enough to warrant recompiling of this beast :)
I would not spend time on xt depend for openoffice. It is quite outdated in portage. openoffice builds a stripped and newer version and is only needed at build-time -> not merged. If you still want to depend on xt update portage's version to latest first and may be strip it like openoffice does. Homepage: http://www.blnz.com/xt openoffice version: http://go-oo.org/packages/xt/ The script to strip xt you can find in xt/downloads/ from openoffice source directory.
Noticed this: --with-db-jar=/usr/share/db-/lib/db.jar Version is missing, probably because db_ver is declared local in pkg_setup, thus empty in src_unpack. You should also probably use db_ver_to_slot because the /usr/share/db-## path (and the java-pkg_get-jar db-## after you convert that) the ## contains slot, not full version. And db has to be built with java USE flag to build db.jar. Doesn't look like from the configure output that it minds db.jar path wrong, or that it would even check it, though.
OO team: system hsqldb is now bumped so it could be depended on and not built also, please apply this in future version, so we migrate to split xalan+xalan-serializer: --- openoffice-2.3.1.ebuild 14 Dec 2007 14:11:55 -0000 1.6 +++ openoffice-2.3.1.ebuild 30 Dec 2007 19:34:41 -0000 @@ -64,6 +64,7 @@ kde? ( >=kde-base/kdelibs-3.2 ) java? ( >=dev-java/bsh-2.0_beta4 >=dev-java/xalan-2.7 + >=dev-java/xalan-serializer-2.7 >=dev-java/xerces-2.7 =dev-java/xml-commons-external-1.3* ) mono? ( >=dev-lang/mono-1.2.3.1 ) @@ -222,7 +223,7 @@ echo "--with-system-xerces" >> ${CONFFILE} echo "--with-system-xml-apis" >> ${CONFFILE} echo "--with-beanshell-jar=$(java-pkg_getjar bsh bsh.jar)" >> ${CONFFILE} - echo "--with-serializer-jar=$(java-pkg_getjar xalan serializer.jar)" >> ${CONFFILE} + echo "--with-serializer-jar=$(java-pkg_getjar xalan-serializer serializer.jar)" >> ${CONFFILE} echo "--with-xalan-jar=$(java-pkg_getjar xalan xalan.jar)" >> ${CONFFILE} echo "--with-xerces-jar=$(java-pkg_getjar xerces-2 xercesImpl.jar)" >> ${CONFFILE} echo "--with-xml-apis-jar=$(java-pkg_getjar xml-commons-external-1.3 xml-apis.jar)" >> ${CONFFILE}
(In reply to comment #12) > OO team: system hsqldb is now bumped so it could be depended on and not built > also, please apply this in future version, so we migrate to split > xalan+xalan-serializer: all that happened now in 2.4.0, thanks for pointing it out
(In reply to comment #13) > (In reply to comment #12) > > OO team: system hsqldb is now bumped so it could be depended on and not built > > also, please apply this in future version, so we migrate to split > > xalan+xalan-serializer: > > all that happened now in 2.4.0, thanks for pointing it out > Just came to my mind, that actually this should fix the original bug, so closing :)