Re: Re: [dev] OOo w/o URE
Hello Stephan, Glad to know that the CWSsd71 have been done and thanks for the following wiki page to describe the details of how these step was reached. I found the followling in the wiki page: Two kinds of changes are necessary: 1.Adapt the code so that it can work for an installation distributed across multiple trees. 2.For specific distributed products, create appropriate installation sets containing appropriate content (e.g., ini/rc files that cater for the distribution of referenced entities). and more detailed list of necessary changes are listed. Our RedOffice team have ability to do some work in the changes list. wish you can allocate some detail tasks to us but need more guide or a developer like a mentor.We can start with some simple tasks. Regards, LiuTao. Stephan Bergmann wrote: FYI: http://odftoolkit.openoffice.org/servlets/ReadMsg?list=devmsgNo=32 See http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE for work on this. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo w/o URE
Hi LiuTao, Thank you for your interest in helping. It is rather hard for me to give you any specific, small, self-contained tasks right now. Work is currently rather proceeding in a way of seeing what broke for OOo-wo-URE and then looking how to fix it. Anyway, I am expanding sb71 in two directions right now, and I would welcome help in both of them: 1 Now that the smoketest succeeds on Unix, use other tests (unit tests, api tests, qatesttool, manual tests) to find things that broke (and fix them once identified). 2 Make OOo-wo-URE work on Windows. The things that need to be done here: 2.1 Introduce the Windows equivalent of the Unix ure-link symlink, so that OOo-wo-URE can locate URE (use a registry entry? there already is one that points to URE). (Where exactly it is currently necessary for OOo-wo-URE to locate URE via ure-link can be found out by grepping for ure-link in the sb71 sources.) 2.2 Make executables and shared libraries in OOo-wo-URE find the shared libraries of URE they depend on (i.e., the Windows equivalent of the Unix ELF RPATH). I hope that Hennes Rohling will provide some solution. 2.3 Examine how the new bootstrap/environment variables set in the Unix start scripts (URE_BIN_DIR, URE_UNORC, URE_JVMFWK3RC) can be set under Windows (where there are no start scripts). -Stephan liutao wrote: Hello Stephan, Glad to know that the CWSsd71 have been done and thanks for the following wiki page to describe the details of how these step was reached. I found the followling in the wiki page: Two kinds of changes are necessary: 1.Adapt the code so that it can work for an installation distributed across multiple trees. 2.For specific distributed products, create appropriate installation sets containing appropriate content (e.g., ini/rc files that cater for the distribution of referenced entities). and more detailed list of necessary changes are listed. Our RedOffice team have ability to do some work in the changes list. wish you can allocate some detail tasks to us but need more guide or a developer like a mentor.We can start with some simple tasks. Regards, LiuTao. Stephan Bergmann wrote: FYI: http://odftoolkit.openoffice.org/servlets/ReadMsg?list=devmsgNo=32 See http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE for work on this. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo w/o URE
Stephan Bergmann wrote: FYI: http://odftoolkit.openoffice.org/servlets/ReadMsg?list=devmsgNo=32 See http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE for work on this. -Stephan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo w/o URE
On Tue, 2007-04-17 at 10:50 +0200, Stephan Bergmann wrote: Stephan Bergmann wrote: FYI: http://odftoolkit.openoffice.org/servlets/ReadMsg?list=devmsgNo=32 See http://wiki.services.openoffice.org/wiki/ODF_Toolkit/Efforts/OOo_without_URE for work on this. That's most excellent, I like the .rdb split, that's where I got stalled when I made a stab at this for last years OOoCon. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo w/o URE
Rüdiger Timm schrieb: Caolan McNamara wrote: On Tue, 2007-02-13 at 09:54 +0100, Stephan Bergmann wrote: FYI: http://odftoolkit.openoffice.org/servlets/ReadMsg?list=devmsgNo=32 Yeah, I'm very much in favour of this myself. Split the build into two parts the API stable ure stuff, and the rest. I'm trying to home-brew some hackery to fake this up. The current practical problems are of course as listed above and [...] So it's certainly kludgy to try and do it right now, but is a very attractive goal for me to be able to just rebuild the portion of OOo affected by whatever bug I've just fixed. And a nice thin edge of a wedge to make OOo more modular at build-time as well as at runtime. C. I also like the idea to modularize products and packages. But I am no friend of splitting it at build time, at least now. For one I still remember times when we here at Sun Hamburg practized such a split between SDK and rest of office. It was quite some effort to reach that split (f.e. separating idl files into two separate modules, 'udkapi' and 'offapi') and some effort to mainatain it. It was unhandy to work with. And we gained nearly nothing. So in the end we again merged both workspaces into one. We gained nothing as there was no demand for a split. This may change in the future (I hope it will). The maintenance effort mainly exists in the heads of the developers: they must make themselves aware of it and act accordingly. IIRC people never tried to understand why we had two idl modules and so they often feeled annouyed. But maybe my memories fool me. Second reason is that (curently) this does not fit our development stile. We do childworkspaces feature wise. With the current degree of code mudularity this quite often means to work on base (URE) modules ^^^ I hope that this is a typo and not a Freudian slip! :-) providing some new functionality and applications where you want to use that in one childworkspace. So, yes, it may be an attractive goal. But we should start with package restructuring and more code modularity. Stick with building on one workspace for now. I agree that it is fortunate to be able to work on a CWS that contains all necessary modules even if they are part of 2 or 3 products. OTOH I think it is essential that we make it easy to build SDK and URE from scratch independently from OOo. This is the kind of split we need. That does not exclude that active development work (CWS) still happens in the integrated environment. As long as all products share the same cvs repository I don't think that this is endangered. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo w/o URE
Mathias Bauer wrote: Rüdiger Timm schrieb: Caolan McNamara wrote: On Tue, 2007-02-13 at 09:54 +0100, Stephan Bergmann wrote: FYI: http://odftoolkit.openoffice.org/servlets/ReadMsg?list=devmsgNo=32 [...] Second reason is that (curently) this does not fit our development stile. We do childworkspaces feature wise. With the current degree of code mudularity this quite often means to work on base (URE) modules ^^^ I hope that this is a typo and not a Freudian slip! :-) Typo :-) BTW, what's 'mudularity'? Sounds interesting, but I don't know such word . providing some new functionality and applications where you want to use that in one childworkspace. So, yes, it may be an attractive goal. But we should start with package restructuring and more code modularity. Stick with building on one workspace for now. I agree that it is fortunate to be able to work on a CWS that contains all necessary modules even if they are part of 2 or 3 products. OTOH I think it is essential that we make it easy to build SDK and URE from scratch independently from OOo. This is the kind of split we need. That does not exclude that active development work (CWS) still happens in the integrated environment. As long as all products share the same cvs repository I don't think that this is endangered. OK. If that's all, 'make it easy to build SDK and URE from scratch independently from OOo', than I am fully with you. It should be possible to check out just a needed subset of modules and build them. Without the need to go through the whole tree just because you need 'instsetoo_native'. But, that's only the first of four paragraphs Stephan wrote concerning 'at build time'. Rüdiger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo w/o URE
Rüdiger Timm schrieb: Mathias Bauer wrote: Rüdiger Timm schrieb: Caolan McNamara wrote: On Tue, 2007-02-13 at 09:54 +0100, Stephan Bergmann wrote: FYI: http://odftoolkit.openoffice.org/servlets/ReadMsg?list=devmsgNo=32 [...] Second reason is that (curently) this does not fit our development stile. We do childworkspaces feature wise. With the current degree of code mudularity this quite often means to work on base (URE) modules ^^^ I hope that this is a typo and not a Freudian slip! :-) Typo :-) BTW, what's 'mudularity'? Sounds interesting, but I don't know such word Doesn't exist, but I hoped that it wasn't the word mud that was going around in your head and slipped into your fingers when you wanted to write modularity. :-) OK. If that's all, 'make it easy to build SDK and URE from scratch independently from OOo', than I am fully with you. It should be possible to check out just a needed subset of modules and build them. Without the need to go through the whole tree just because you need 'instsetoo_native'. But, that's only the first of four paragraphs Stephan wrote concerning 'at build time'. Yes, I only presented my personal POV. For users and developers of OOo there wouldn't be much they could get from separated builds. That's clearly something for people that don't want to build OOo. So for me the ability to build and work on URE and ODK separately while still keeping the OOo build environment would be sufficient. Stephan's mileage may vary of course. Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo w/o URE
Stephan Bergmann schrieb: Mathias Bauer wrote: Rüdiger Timm schrieb: OK. If that's all, 'make it easy to build SDK and URE from scratch independently from OOo', than I am fully with you. It should be possible to check out just a needed subset of modules and build them. Without the need to go through the whole tree just because you need 'instsetoo_native'. But, that's only the first of four paragraphs Stephan wrote concerning 'at build time'. Yes, I only presented my personal POV. For users and developers of OOo there wouldn't be much they could get from separated builds. That's clearly something for people that don't want to build OOo. So for me the ability to build and work on URE and ODK separately while still keeping the OOo build environment would be sufficient. Stephan's mileage may vary of course. One idea behind the separation of URE and OOo is that you have one URE installed on your machine and potentially many other applications that use it (OOo, an ODF toolkit in whatever form, etc.). Sine URE and OOo are potentially deployed into different locations (e.g., /opt/openoffice/ure vs. /opt/openoffice2.2), this means that the OOo-specific code will no longer find the general URE code right next to it. And that would also probably have implications on the build environment, as I detailed in my original post. Making URE more easily buildable inside the current OOo build environment is one possible (first) step. The complete picture would go further, however, and that is where Rüdiger's concerns would kick in. Understood, but I think we should start with the first step as it seems to be uncontroversal and it already helps a lot. When we start to implement the complete picture it should be possible to address any concerns that still might exist then. So if people could build the URE and the SDK easily they would be able to use it as we wanted them to use it. Wether we deployed OOo in a way that allowed to share a common URE installation later on shouldn't be important currently, though it surely should be the final goal if we take the idea of the ODF toolkit seriously. I think if Rüdigers' concerns were still valid they would be a clear sign that the separation between the URE and OOo is not really done and that there are still too much dependencies. OTOH if both indeed are separated enough the necessary changes in the build environment shouldn't make problems. Why should anybody have one CWS that contains sources from OOO *and* URE then? Or do I overlook something? Ciao, Mathias -- Mathias Bauer (mba) - Project Lead OpenOffice.org Writer OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS Please don't reply to [EMAIL PROTECTED]. I use it for the OOo lists and only rarely read other mails sent to it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo w/o URE
Caolan McNamara wrote: On Tue, 2007-02-13 at 09:54 +0100, Stephan Bergmann wrote: FYI: http://odftoolkit.openoffice.org/servlets/ReadMsg?list=devmsgNo=32 Yeah, I'm very much in favour of this myself. Split the build into two parts the API stable ure stuff, and the rest. I'm trying to home-brew some hackery to fake this up. The current practical problems are of course as listed above and [...] So it's certainly kludgy to try and do it right now, but is a very attractive goal for me to be able to just rebuild the portion of OOo affected by whatever bug I've just fixed. And a nice thin edge of a wedge to make OOo more modular at build-time as well as at runtime. C. I also like the idea to modularize products and packages. But I am no friend of splitting it at build time, at least now. For one I still remember times when we here at Sun Hamburg practized such a split between SDK and rest of office. It was quite some effort to reach that split (f.e. separating idl files into two separate modules, 'udkapi' and 'offapi') and some effort to mainatain it. It was unhandy to work with. And we gained nearly nothing. So in the end we again merged both workspaces into one. Second reason is that (curently) this does not fit our development stile. We do childworkspaces feature wise. With the current degree of code mudularity this quite often means to work on base (URE) modules providing some new functionality and applications where you want to use that in one childworkspace. So, yes, it may be an attractive goal. But we should start with package restructuring and more code modularity. Stick with building on one workspace for now. Rüdiger - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [dev] OOo w/o URE
On Tue, 2007-02-13 at 09:54 +0100, Stephan Bergmann wrote: FYI: http://odftoolkit.openoffice.org/servlets/ReadMsg?list=devmsgNo=32 Yeah, I'm very much in favour of this myself. Split the build into two parts the API stable ure stuff, and the rest. I'm trying to home-brew some hackery to fake this up. The current practical problems are of course as listed above and that to e.g. build the sdk separately from OOo and then to build OOo against that sdk+ure combination you need to have a) config_office, dmake, solenv, instsetoo_native, soltools, scp2 and readlicense_oo in both the sdk+ure and OOo build trees b) have bridges, cli_ure, codemaker, cppu, cppuhelper, cpputools, idlc, io, javaunohelper, jurt, jvmaccess, jvmfwk, offapi, offuh, rdbmaker, registry, remotebridges, ridljar, sal, salhelper stlport, stoc, store, udkapi, ure, unoil, xml2cmp, odk, sdk_oo autodoc, udm, cosv, unodevtools, jut in the ure tree b) and jvmfwk3rc and unorc are generated in the ure tree for both itself and for the final OOo product, as well as the forementioned .rdb files so you need to cheat and stick them into a package generated from the ure build and reuse them from inside the OOo build and then fiddle with some variables to add the sdk includes and the ure libs to the SOLARINC and SOLARLIB etc. So it's certainly kludgy to try and do it right now, but is a very attractive goal for me to be able to just rebuild the portion of OOo affected by whatever bug I've just fixed. And a nice thin edge of a wedge to make OOo more modular at build-time as well as at runtime. C. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
