I wanted to setup a fresh instance of Dataverse using the latest develop branch, but I am stuck at the Payara page. I have used the following command to set it up:
mvn -Pct clean package docker:start
Do you have advice how to fix this?
Hmm, first, I always use docker:run and I'm not sure what the difference is.
Since you want a clean start, I would suggest rm -rf docker-dev-volumes
See also https://guides.dataverse.org/en/6.5/container/dev-usage.html where we document this. Or https://guides.dataverse.org/en/6.5/container/running/demo.html#deleting-data-and-starting-over but the directory has a different name.
Thanks @Philip Durbin โ๏ธ - Will try it :smile:
I was able to fix it, at least for a short time. Using the develop branch has led to the backend not properly starting. So I checked the v6.5 tag and voila it worked.
I did restart the containers and now I am running into the same problem again. Tried other tags, but neither of them worked. In between those I have deleted images and dev-volumes, but that did not help.
Looking at the logs I received a couple of Severe errors, but I have no clue what the issue is. Do you have an idea, how I could fix this? Running on an M3Pro with Docker Desktop. Attached the logs
Uh oh, the dreaded ConfigCheckService
When you see this, you should always scroll up to see what it's complaining about.
"No PID providers configured"
"No default PID provider configured"
Strange. You're using docker-compose-dev.yml from the root of the repo, right?
Thanks for the heads up! I've been using the vanilla docker compose of v6.5 and mvn
Yes, I have not modified it
Before you mentioned using this:
mvn -Pct clean package docker:start
Instead, have you tried this?
mvn -Pct clean package docker:run
I don't know if it makes a difference.
Tried both of them, but it did not make a difference. I sweeped my docker installation and am trying again with a fresh installation. Maybe there are some Docker-related issues.
Is using the 6.5 tag for now an ok workaround?
Using the tag did not work either. Worked for a short period and then it was broken again. I suspect it is something with my system or setup.
Oh, I see. Hmm.
Did you restart Docker? I'm grasping at straws here. :sweat_smile:
I might need to call for reinforcements. Someone like
@Oliver Bertuch ![]()
Yes, did restart a couple of times and also my machine. Did not help unfortunately. I hope re-installation of Docker helps
Fresh docker instance did not help. Maybe I need to restart my machine again
Do you want to try the "demo and eval" compose file? It uses a different PID provider (Permalinks): https://github.com/IQSS/dataverse/pull/11108
Or do you need certain functionality in the dev compose file, such as S3?
I'm just trying to get you unblocked.
I need the S3 functionality unfortunately
ok
Each time is it complaining about PID providers?
I am puzzled to why it worked for a short period and then stopped working. One last instance I could try is to use a different platform and switch to amd64
yeah, very strange
Trying v6.3 now. That was the last version I've been using most of the time
Tried downgrading docker desktop and cycled through all 6.x release, but without success. Keep running into the same issues :frown:
I'm running into my own problems but I started a new topic for that: #containers > Docker trouble on macOS 15 ![]()
Updating macOS did not solve the problem :frown:
No problems with your Docker, right?
Should we do a quick call?
Haven't run into issues with other containers. Could it help if I send you the logs?
Well, the logs still complain about the PID provider, right? Or do they vary?
I am currently with my friends, but a call tomorrow would be awesome :smile:
If that works for you
You could join the container meeting if you like :smile: #containers > weekly meeting
Sounds great, will join
Great. I already had your issue on the agenda :crazy:
@Jan Range when you encounter this trouble, what \pid\ jvm-options make it into domain.xml?
https://github.com/gdcc/dataverse-action is still working, right?
Sorry, I've been sick until recently :frown:
@Philip Durbin โ๏ธ yes the action still works. That's why I am a bit puzzled.
@Don Sizemore thanks for the hint, will look into this!
I am still struggling to run the containers :frown:
@Don Sizemore seems like the PID option does not appear in domain.xml. I have attached the file and the container log.
Tried re-installing Docker, Java and down to DV 6.1, but nothing really helped. I think my system has turned against me :sob:
What puzzles me is that the GH Action works perfectly fine, and I guess yours too @Philip Durbin โ๏ธ although we are on the same OS. There seems to be a tiny thing that is causing these issues, but its the needle in the haystack :grinning:
Bah, so frustrating. Maybe you and I can get on a Zoom call sometime to troubleshoot this. But not now. I'm going home for the day. :person_running_facing_right:
Sounds great! Would Friday work for you? I am on the road tomorrow
I managed to resolve the issue! I'm unsure what triggered it, but the Java version of mvn was misaligned with my global JDK 17. At one point, it seems to have switched to JDK 23, and this has caused the issue. I changed it back to JDK 17, and now it works perfectly :raised_hands:
Jan Range has marked this topic as resolved.
Phew! Glad to hear!
Finally, so happy :heart_eyes:
@Omer M Fahim just had a similar problem. Got a new laptop. Installed the latest Java. Got errors like "No PID providers configured" and "No default PID provider configured". I'm having him try the correct, older version of Java (17).
It would be nice to have this "fail fast", if you will. Show immediately that a different version of Java is required.
Philip Durbin โ๏ธ has marked this topic as unresolved.
Ok, I made a draft PR: enforce Java 17 (no higher) #11487
@Oliver Bertuch please take a look! :heart:
@Philip Durbin I reverted your commit and fixed the root cause - when introducing auto-services, we missed a config bit for the compile plugin. Took the liberty to push into your PR branch.
"When using Java 21 (Temurin LTS), I cannot reproduce the issue. Works!"
This is odd because I was testing with 21.0.4-tem.
When you say "works" do you mean that Dataverse was completely up and working?
I see @Leo Andreev already approved the PR, by the way.
This is a case where I probably should have opened an issue (or asked @Omer M Fahim to, since him hitting the bug prompted me to take a look). That way, we could close my PR as the wrong fix and have a new PR from you as the right one.
Yeah it worked without a flaw on 21 for me ![]()
I suspect there was some kind of change in JDK 23 how to deal with annotation processors.
But I'm using 21.
However, now it's setup properly and doesn't come back to bite us again when we move on to newer JDKs.
Should we change (in the dev guide)
"First, install Java 17, Maven, and Docker."
to
"First, install Java 17+, Maven, and Docker."
?
I'm happy with whatever. My only concern is to ship it ASAP :see_no_evil:
I thought we were locked to 17
Why would we?
because of all the problems @Jan Range and @Omer M Fahim had :smile:
We're just making sure to compile it with support for 17 and should be good to go
Ha!
that I was able to reproduce on 21
I mean, poor Jan suffered for weeks!
So if I run mvn clean compile on 21, all three files are generated.
mvn --version
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Maven home: /home/obertuch/.sdkman/candidates/maven/current
Java version: 21.0.7, vendor: Eclipse Adoptium, runtime: /home/obertuch/.sdkman/candidates/java/21.0.7-tem
Default locale: de_DE, platform encoding: UTF-8
OS name: "linux", version: "6.14.9-200.fc41.x86_64", arch: "amd64", family: "unix"
ls -la target/classes/META-INF/services
insgesamt 12
drwxr-xr-x. 1 obertuch obertuch 278 4. Jun 15:25 .
drwxr-xr-x. 1 obertuch obertuch 264 4. Jun 15:25 ..
-rw-r--r--. 1 obertuch obertuch 423 4. Jun 15:25 edu.harvard.iq.dataverse.pidproviders.PidProviderFactory
-rw-r--r--. 1 obertuch obertuch 488 4. Jun 15:25 io.gdcc.spi.export.Exporter
-rw-r--r--. 1 obertuch obertuch 64 4. Jun 15:25 org.eclipse.microprofile.config.spi.ConfigSourceProvider
should I try it? on develop?
or do we not care?
Maybe try the fix? :see_no_evil:
ha, from from enforce-java-17 branch :smile:
% mvn --version
Apache Maven 3.9.8 (36645f6c9b5079805ea5009217e36f2cffd34256)
Maven home: /Users/PDurbin/.sdkman/candidates/maven/current
Java version: 21.0.4, vendor: Eclipse Adoptium, runtime: /Users/PDurbin/.sdkman/candidates/java/21.0.4-tem
Default locale: en_US, platform encoding: UTF-8
OS name: "mac os x", version: "15.5", arch: "aarch64", family: "mac"
After mvn clean compile:
% ls -la target/classes/META-INF/services
total 24
drwxr-xr-x 5 PDurbin staff 160 Jun 4 09:31 .
drwxr-xr-x 9 PDurbin staff 288 Jun 4 09:31 ..
-rw-r--r-- 1 PDurbin staff 423 Jun 4 09:31 edu.harvard.iq.dataverse.pidproviders.PidProviderFactory
-rw-r--r-- 1 PDurbin staff 488 Jun 4 09:31 io.gdcc.spi.export.Exporter
-rw-r--r-- 1 PDurbin staff 64 Jun 4 09:31 org.eclipse.microprofile.config.spi.ConfigSourceProvider
Jan Range said:
At one point, it seems to have switched to JDK 23
No suffering because of JDK 21 for Jan :smiley_cat:
Hmm, I wonder what Omer was on.
:ship: :ship: :ship: :ship: it!
dev_bootstrap> Done, your instance has been configured for development. Have a nice day!
I'm looking at this PR: Upgrade to Java 17 #9764
It looks like a lot of our CI is still on Java 17.
So maybe I'll update the dev guide to say 17+ but explain that the CI uses 17.
IIRC all of it
Maybe keep it at 17.
Less moving parts
yeah?
Let folks use what is proven to work
But unblock if they want to try...
That way we might learn about bumps in the road when we go for a newer version
Jan and Omer would have been on 21 or 23 or whatever. That's what we want?
Maybe Omer should switch to 17 for QA. It should be safe to use newer versions, but there's no guarantee. Fun game of whack-a-mole.
Eventually we'll need to upgrade anyway. 17 EOL is not far away. https://endoflife.date/eclipse-temurin
My suggestion would be to start migrating to a newer Java version when we migrate to Jakarta EE 11. That might be Temurin 25 LTS by the time.
EE 11 will be enforcing Java 17 and recommending 21. https://jakartaee.github.io/platform/jakartaee11/JakartaEE11ReleasePlan But there are some real nice features in the newer Java versions... :smiley:
Maybe some day we'll do a grand refactoring and make use of that...
I made a little doc change: https://github.com/IQSS/dataverse/pull/11487/commits/c27c57b93df8624402ad49f5a1f89da07dbd2243
Reads good to me :smile_cat:
Do these two little PRs now count as fast trackable as they have docs? :smiling_devil:
Sorry, what's the second PR?
https://github.com/IQSS/dataverse/pull/11547 (no Zulip topic, shame!)
Oliver Bertuch has marked this topic as resolved.
Ah, @Leo Andreev approved that one too. :smile:
Last updated: Oct 30 2025 at 05:14 UTC