Where do the file refine.ini is to be created to use with the MacOS compiled version

[Antoine2711]

I want to create a refine.ini file to use with the MacOS compiled version. I’ve tried to create the file in two places:
/Applications/OpenRefine.app/Contents/MacOS
and
/Applications/OpenRefine.app/Contents/Resources
but both do not seem to work…

@tfmorris, any clue, since you’re also a Mac user…

Regards, Antoine

[tfmorris]

I want to create a refine.ini file to use with the MacOS compiled version.

That ini file is read by the refine/refine.bat scripts, which aren't used in the production versions.

If you want to change or add JVM arguments or set properties which are used by OpenRefine, you can edit the Info.plist file in the package.

• right click on the OpenRefine app icon and select Options -> Show in Finder
• right click on the entry in Finder and select Show Package Contents
• open Info.plist in a text editor
• scroll to the bottom and look for the key JVMOptions

Tom

[thadguidry]

@Antoine2711 would you mind updating our docs with that info? Thanks!

[Antoine2711]

@thadguidry: actually, yesterday, I added to our docs the 3 JVM preferences for gdata.
This morning, @antonin_d approved my changes, so that part in now in the docs. It was on the Wiki page for the gdata extension. I think we should add a page in ours docs for the extensions, with a user point of view. In there, you could point to the Wiki page for the gdata.

For the infos for the Info.plist, it's already in our docs. I've used it a few time for the memory JVM preference.

@tfmorris: once you mentionned that there was no refine script in the compiled version, it made sense that there was no need for refine.ini. But I still find it not easy even for power users to change that. I'll come back with suggestions.

Regards, Antoine

[thadguidry]

My preference actually is for the extensions website page just move over under /docs/ perhaps as a last menu item in the sidebar top-level hierarchy?

• User Manual
• Contributing to OpenRefine
• Extensions

where Extensions can then have nice subpages and hierarchy itself and much easier to grow out and manage via Docusaurus /docs instead of /pages

Then at the top of the nav bar of the site, between Community and Blog, we put Extensions, to make is quick and easy to navigate for users into the sidebar hierarchy.

That was my suggestion to @Martin on a call a few months ago.

[Antoine2711]

@thadguidry: I think this is interesting.

I would go a bit further, and create a section with individual pages for all the extensions and services.

I say you have a PR for the migration of the configuration of the “Google Data extension”. I need its own page.

Here’s the post I did for that:

Improving the documentation with a new section, “External tools and Services”

I would like to have more available informations on the external tools, clients and services (particularly the Reconciliation services, except Wikidate/wikibase/Wikimedia Commons). A new section for that would make it easillier to write and display more information. Is this something other people would like to see/use? Regards, Antoine

Regards, Antoine

[thadguidry]

I would do those only for the extensions that the OpenRefine team has some direct relationship towards. For external extensions, I think their own GitHub Wiki's or websites should be used.

Since this is about the gdata extension that we maintain (or have traditionally), yes it makes sense, I think, for us to have a page about it in our docs.