JabRef-build-snapshot killed my stable JabRef-3.8.1

Help
1

Because of that comment in GitHub I tried the current development version of JabRef. But after that my stable JabRef (3.8.1 from Debian unstable) doesn’t start anymore.

I don’t understand the debug output here. What is wrong and why did this happen?

$ jabref --version --debug
[warning] /usr/bin/jabref: Unable to locate mysql-connector-java in /usr/share/java
[warning] /usr/bin/jabref: Unable to locate postgresql in /usr/share/java
22:41:33.458 [AWT-EventQueue-1] DEBUG net.sf.jabref.logic.logging.JabRefLogger - Showing debug messages
JabRef 3.8.1
22:41:33.461 [AWT-EventQueue-1] DEBUG net.sf.jabref.cli.ArgumentProcessor - Finished export
22:41:33.461 [AWT-EventQueue-1] DEBUG net.sf.jabref.logic.remote.server.RemoteListenerServerThread - Interrupting JabRef - Remote Listener Server on port 6050
22:41:33.461 [FileUpdateMonitor] DEBUG net.sf.jabref.collab.FileUpdateMonitor - FileUpdateMonitor has been interrupted. Terminating...
java.lang.InterruptedException: sleep interrupted
	at java.lang.Thread.sleep(Native Method) ~[?:1.8.0_121]
	at net.sf.jabref.collab.FileUpdateMonitor.run(FileUpdateMonitor.java:43) [JabRef-3.8.1.jar:?]
	at net.sf.jabref.JabRefExecutorService$NamedRunnable.run(JabRefExecutorService.java:98) [JabRef-3.8.1.jar:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [?:1.8.0_121]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [?:1.8.0_121]
	at java.lang.Thread.run(Thread.java:745) [?:1.8.0_121]

A --reinstall didn’t help, too.

2

The new version changes the way the group tree is serialized and this leads to problems in older version. As a workaround you can remove the @Comment{jabref-meta: groupstree: part of your bib file or at least remove the trailing semicolons (only \;; should be at the end) and change StaticGroup to ExplicitGroup.

3

I think I missunderstood you.

When I remove @Comment{jabref-meta: groupstree: the complete grouptree is gone. This makes the situation more worst then before.

Your other solution was to “remove the trailing semicolons”. Can you give me an example with that line please?

2 ExplicitGroup:JabRef\;0\;1\;\;\;\;;

There is only a \;; at the end.

4

It should only be 1 ExplicitGroup:Name\;0\;;

5

Thank you very much, it works again. You saved me.

But IMO my case brougth up some elementary problems.
Plesae let me say first that I knew of course that working with a development snapshot is at high and my own risk!

The debug output of JabRef3.8.1 I posted. I couldn’t find a hint in it which bib-file it tried to open and that a problem occured while opening it. Maybe I missunderstand that output? If not I would recomment to improve the console/debug output at that point. If you agree I would open an issue for that.

The dev-snapshot reformated the bib-file in that way it wasn’t backwards compatible. This is ok but should be done transparent and more communicative!

2a.
An extra backup (not the default bak-file) should be done automaticly if a bib-file is transformed that way. Name it e.g. myfile.bib.3.8.1.bak. Issue for that?

2b.
Such a transformation (including the name of the extra backup file) should be clear communicated to the user. A message dialog should be opened to inform that user about the transformation and that there is no way back (except with the extra backup file). Issue for that?

6

I think you raise good points, however, I fear that we don’t have the resources to really implement them.
ad 1: Yes, the debug messages are sometimes not really helpful.
ad rest: We will definitely write some warning words in the release notes of 4.0. Maybe even display a warning message at the first start of 4.0…but extra backup or something like that is not easily possible. Can you please add a short note in the “group things for 4.0” issue at github as a reminder. Thanks!