Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Replace jdatapath dependency with Java 8 user home directory finding #2961

Closed
tfmorris opened this issue Jul 18, 2020 · 6 comments · Fixed by #3840
Closed

Replace jdatapath dependency with Java 8 user home directory finding #2961

tfmorris opened this issue Jul 18, 2020 · 6 comments · Fixed by #3840
Assignees
Labels
maintainability Making it easier to maintain OpenRefine packaging How we distribute OpenRefine to end users, on various operating systems Platform: Windows Indicates that the issue or feature is specific to the Windows operating system. Type: Feature Request Identifies requests for new features or enhancements. These involve proposing new improvements.
Milestone

Comments

@tfmorris
Copy link
Member

We currently use an obscure dependency, jdatapath, to find the user's home directory on Windows. Since Java 8 was taught how to do that correctly itself, we should switch to that and drop the dependency.

System.getProperty("user.home") or org.apache.commons.lang3.SystemUtils.getUserHome()

https://stackoverflow.com/questions/585534/what-is-the-best-way-to-find-the-users-home-directory-in-java

@tfmorris tfmorris added Type: Feature Request Identifies requests for new features or enhancements. These involve proposing new improvements. maintainability Making it easier to maintain OpenRefine labels Jul 18, 2020
@tfmorris tfmorris changed the title Replace jdatapath dependency of Java 8 user home directory finding Replace jdatapath dependency with Java 8 user home directory finding Jul 18, 2020
@StoltHD
Copy link

StoltHD commented Aug 7, 2020

How about you let the users select where they want things to be themself?

Not everyone wish to have their data stored on the C-drive on Windows, and not everyone knows how to change the path to their home folder for the system. And not everyone knows how to create sym-links to redirect a file or folder location.

Projects and workload areas should always be allowed to be chosen by the user...

I.e. some people may have 2 really fast nvme ssd's in their system, one relatively small for the OS (C: drive on Windows) and a larger one for workloads, cache folders and other active projects, while they save long time data on a larger HDD.

It would be great to be able to select the active work folder and cache folder without digging into system paths and manually setting java settings...

Just a suggestion...

@thadguidry
Copy link
Member

Hi @StoltHD You can set the workspace folder location refine.data_dir ... in the refine.ini file using JAVA_OPTIONS. Take a look!

# Some sample configurations. These have no defaults.
#JAVA_HOME=C:\Program Files\Java\jdk1.8.0_151
# Use a single JAVA_OPTIONS that includes any JVM options you need upon OpenRefine startup
#JAVA_OPTIONS=-XX:+UseParallelGC -verbose:gc -Drefine.headless=true -Drefine.data_dir=C:\Users\user\AppData\Roaming\OpenRefine

Or you can specify a JAVA_OPTIONS along with refine.bat just with a Windows desktop shortcut as you would with any CMD line program on Windows.

Thought: For even more convenience (even for making your shortcuts to the refine.bat file with options, we could add a new refine.bat option such as /f to specify the OpenRefine data folder if you think that would make things easier?

@StoltHD
Copy link

StoltHD commented Aug 7, 2020

Thanks for answering, I did find it after some digging and try and fail, I use the "exe" file and had to set it in the "openrefine.l4j.ini" file... not very logical when most Windows applications use a "appname.ini", "settings.ini" or "config.ini" file.
... but my problem at the end was that the parameters in the different files are somehow different...

Du you really need to have 3-4-5 different ways to set initial configurations?

And one more thing, is it somehow possible to check that Openrefine actually utilize the 4-8-10-16-24-32GB (or more) of ram I set it to use, before I run any cleanup/addition on a large dataset and it crash?

There are a few settings and a few system (java) calls that would be really great to be able to "just use" without digging down and using lots of time reading all types of forums and comments on github...
I am lucky, I actually know where to look, and I am not affraid asking stupid questions, but I know a few people that stopped using Openrefine even before they started because they din't figure out how to do simple pre-use configurations..

Thank you for answering so fast, its over a year now since I last used Openrefing because I gave up trying to figure out the settings I needed.

I really appreciate you took your time to answer.

@thadguidry
Copy link
Member

@StoltHD You will find that in the Windows console when OpenRefine runs that the beginning part of the log will confirm what amount of memory you are using:

...
17:28:43.504 [            refine_server] Starting Server bound to '127.0.0.1:3333' (0ms)
17:28:43.505 [            refine_server] refine.memory size: 4000M JVM Max heap: 4194304000 (1ms)
17:28:43.518 [            refine_server] Initializing context: '/' from 'E:\GitHub Repos\OpenRefine\main\webapp' (13ms)
SLF4J: Class path contains multiple SLF4J bindings.
...

I agree that we could certainly add that somewhere on the main OpenRefine screen upon first startup to make this easier to see.

@StoltHD
Copy link

StoltHD commented Aug 8, 2020 via email

@tfmorris
Copy link
Member Author

tfmorris commented Aug 8, 2020

Maybe I should create a seperate issue for this

Yes, please do. Also if you'd like to suggest that the data directory be split from the location of the core metadata, feel free to create an issue for that.

Let's focus the discussion in this issue on the topic of replacing the jdatapath dependency and move all other discussion elsewhere. Thank you.

@wetneb wetneb self-assigned this Apr 21, 2021
wetneb added a commit to wetneb/OpenRefine that referenced this issue Apr 22, 2021
wetneb added a commit to wetneb/OpenRefine that referenced this issue Apr 22, 2021
@wetneb wetneb added the packaging How we distribute OpenRefine to end users, on various operating systems label Jun 10, 2021
wetneb added a commit that referenced this issue Jun 10, 2021
…3840)

* Use environment variables for default workspace location on Windows, for #2961.

* Mention possibility of using System.getProperty instead

* Migrate to user.profile java property for Windows workspace dir fallback
@wetneb wetneb added the Platform: Windows Indicates that the issue or feature is specific to the Windows operating system. label Jun 10, 2021
@wetneb wetneb added this to the 3.5 milestone Jun 10, 2021
wetneb added a commit that referenced this issue Jun 10, 2021
…3840)

* Use environment variables for default workspace location on Windows, for #2961.

* Mention possibility of using System.getProperty instead

* Migrate to user.profile java property for Windows workspace dir fallback
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
maintainability Making it easier to maintain OpenRefine packaging How we distribute OpenRefine to end users, on various operating systems Platform: Windows Indicates that the issue or feature is specific to the Windows operating system. Type: Feature Request Identifies requests for new features or enhancements. These involve proposing new improvements.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants