Please portablize the Class Folder/Archive settings on each OOP startup.
I understand the launcher is designed to find Java either on the host machine or in one of two standard folders within the PortableApps structure. That works great, but it also blanks the Class Folder/Archive settings in the process, which breaks features in Base associated with client-server database access through Base and OpenOffice data sources.
Specifically, it breaks OpenOffice access to Java classes in 'javasettings_Windows_x86.xml' ...
It changes this line:
userClassPath xsi:nil="false" C:\PortableApps\OpenOfficePortable\App\openoffice\Basis\program\classes;C:\PortableApps\OpenOfficePortable\App\openoffice\Basis\program\classes\hsqldb.jar
/userClassPath
Into this line:
userClassPath xsi:nil="true"
Perhaps this logic would work:
(1) Read the existing 'javasettings_Windows_x86.xml' file during launch, and parse the 'userClassPath' entry to determine the filename of each jar file specified in the string.
(2) Do the normal magic and rewrite this file as you do now, but with one addition...
(3) Use the 'OpenOfficePortable' folder path to further generate the path to the 'classes' folder.
(4) Assume all jar files will/must be stored in the standard 'classes' folder (as shown above).
(5) Use this path to the 'classes' folder to build the folder and jar file strings for each file found in step 1.
(6) Save the generated strings to the key in the new 'javasettings_Windows_x86.xml' file.
This should effectively portablize 'userClassPath' settings.
Thank you for this consideration.
Visit the Community page
Join our forums
Subscribe to our email newsletter
Subscribe with RSS
Follow us on BlueSky
Follow us on Facebook
Follow us on LinkedIn
Follow us on Mastodon
as You said it here:
http://www.oooforum.org/forum/viewtopic.phtml?p=363191#363191
But You ignore what portable usage means. Why? Your 'solution' (use sbase executable directly) could solve Your problem but will break the portable mode.
At the moment there a some limitations for the advanced usage of base, but we will solve it as soon as possible.
There is no easy way to implement the way You've posted here, cause there are no real good working way for parsing xml files. It takes some time to do it. If You are able to do it (and do it quicker than us) You are invited to post the NSIS code here.
That's what OSS means, use the available sources, offer help or do the job if You are able to do it but don't say 'They ignore me' if the answer will take some time.
Paid for Software more or less?
What You need is OSS!
I may have a way of doing it. I'll try and get it into 3.2 Rev 2. Marko, does your 3.2 (revised) build environment already fix all other known issues?
Sometimes, the impossible can become possible, if you're awesome!
without changes on the loader or something else, that's why I only send the batch to You on March the 4th.
We still need a better handling for the paths, in order to give the users a secure way to change it (all) over OpenOfficePortable.ini or to switch the path handling completely off for advanced usage. That's the only open issue together with the java problems.
Thank You for Your quick reply
Paid for Software more or less?
What You need is OSS!
John & MarkoMLM,
If you have a solution ready to go that supports 'javasettings_Windows_x86.xml' settings in portable environments, then that will be optimum -- and thank you!
But I just wanted to let you know that we've discovered a workaround that adds default support for the built-in HSQLDB engine, and it works in portable environments as well. This is important support because the default, all-in-one, odb-file database has proven unreliable throughout the user community. Specifically, the zip-translation tasks combined with OpenOffice.org instabilities are causing total, unrecoverable, data loss through .odb file corruption. We (including the lead HSQLDB maintainer, Fred Toussi) have proposed a 'file:' or 'server' mode HSQLDB database as an immediate solution using only the built-in OOo components. Users can add this 'default' support and "Create a new 'file: mode' database" using the available cross-platform? (.jar) installers, which I've used succcessfully to update OOP on my flash drive.
The .ini file modification might be something to consider for OOP, since it simply adds default support for the built-in HSQLDB engine without user intervention.
background info: http://www.oooforum.org/forum/viewtopic.phtml?p=379793#379793
and installers: http://www.oooforum.org/forum/viewtopic.phtml?p=396523#396523
Well thank both of you for the replies and coding efforts!!!
I had no idea anyone had acknowledged this issue/suggestion and was actually working towards a solution. I was trying to be solutions-oriented here, and perhaps I was fishing for a reply and I'm sorry. I'm very accustomed to workarounds, and I don't expect support for obscure uses of an application. But Base is now celebrated as a premier, desk-top, front-end development tool and users increasingly expect multi-user access to their data (like MS Access) -- which is enabled by client-server configuration.
I understand "portable" goals and believe we're both trying to provide users with the necessary workarounds under the circumstances, whether through user-permissions or a secondary shortcut. sBase.exe is only used for subsequent OOP starts -- after the portable launcher is used first -- in each portable environment, as outlined. That solution doesn't break portability per-se because it uses the portable launcher to create the xml settings first, and then hands the duties over to sBase.exe to keep the settings intact for that environment. Are you saying sBase.exe writes to the registry or creates other tracks on the machine in this case? If so, that's really a secondary issue here, and it's not all that uncommon in the "portable" world, albeit much less common in the PortableApps.com world. But I would like to know if sBase.exe lays tracks on the host machine...?
I'm sorry but I can't offer a coded solution. My xml parsing experience is very limited and involves OOo-Basic utilizing pre-filled Base rowsets to identify and parse known iCalendar headers, tags, and footers. But I never completed the functionality (parsing) because I found it wasn't necessary for the particular application. I guess I could post what I've got.
And now that I think about it, I didn't mean parse the xml...I meant parse the singular ClassPath ASCII string in order to identify each folder or filename before each semi-colon ( ; ) in the string. It's all one string in my experience, so perhaps that simplifies things since it's just a matter of looking for the semicolons and grabbing the characters right-to-left (backwards) until you reach a forward-slash. In other words, each folder or filename is located one after another in a single ClassPath string and uniquely between a forward-slash and semi-colon. The folders don't have a .jar extension. I hope that helps with the difficulty.
I've fully embraced the portable model since 2006 and led countless satisfied users your way. I'm greatly indebted to the leadership and coding efforts provided by John and dedicated individuals such as yourself. This is a heartfelt thank you!
The original issue of it losing the classpaths entirely was fixed quite some time ago with the switch to the PA.c Launcher. I added portablization of the classpaths in the OpenOffice Portable 4.1.6 release in case anyone still needs it.
Sometimes, the impossible can become possible, if you're awesome!