Jabref: Problem when building from source for v4.1

[aytekinar]

• [ ] I have tested the latest master version from http://builds.jabref.org/master/ and the problem persists

Hey,

I am having problems installing JabRef from source, which I could do before. Apparently, there is some usage of a deprecated function (see the tail of the log below). I am not sure if I can solve this problem myself, or I should simply install from master. I would like to track if at all possible the tagged versions.

===

JabRef version v4.1 on Arch Linux.

Steps to reproduce:

 ~/D/M/R/JabRef   master   git checkout -b install v4.1
Switched to a new branch 'install'
 ~/D/M/R/JabRef   install   gradle --version

------------------------------------------------------------
Gradle 4.4.1
------------------------------------------------------------

Build time:   2017-12-20 15:45:23 UTC
Revision:     10ed9dc355dc39f6307cc98fbd8cea314bdd381c

Groovy:       2.4.12
Ant:          Apache Ant(TM) version 1.9.9 compiled on February 2 2017
JVM:          1.8.0_144 (Oracle Corporation 25.144-b01)
OS:           Linux 4.14.14-1-ARCH amd64

 ~/D/M/R/JabRef   install   gradle releaseJar

Log File

```

Task :compileJava
Processing annotations
Annotations processed
Processing annotations
No elements to process
/home/aytekin/Documents/My_Gits/Research/JabRef/src/main/java/org/jabref/logic/citationstyle/CitationStyle.java:156: error: [StreamResourceLeak] Streams that encapsulate a closeable resource should be closed using try-with-resources
List allStyles = Files.find(jarFs.getRootDirectories().iterator().next(), 1, (file, attr) -> file.toString().endsWith("csl")).collect(Collectors.toList());
^
(see http://errorprone.info/bugpattern/StreamResourceLeak)
Did you mean 'List allStyles ;'?
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
1 error

FAILURE: Build failed with an exception.

• What went wrong:
  Execution failed for task ':compileJava'.

  Compilation failed with exit code 1; see the compiler error output for details.

• Try:
  Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights.

• Get more help at https://help.gradle.org

BUILD FAILED in 40s
4 actionable tasks: 4 executed
```

[Siedlerchr]

Hi, this is a bug we recently fixed. I suggest you direclty compile the latest master.

[aytekinar]

I am asking just out of curiosity: would it not be possible to have semantic versioning that also includes patches like, e.g., v4.1.1? Or, is master always stable? I was preferring tagged versions, as they do imply the version is stable, but I do not know of your policy, of course :)

[Siedlerchr]

Hi, we do not follow semantic versioning, but we have tags for the release versions. Due to time and manpower constraints (we all work in our freetime on this project) we do not maintain release branches.
So, the master is always based on the latest release version + new features/bug fixes which have been merged since release, the latest commit level.

Just out of curiosity: Why don't you use prebuilt jar version of the release?

[aytekinar]

Hi, we do not follow semantic versioning, but we have tags for the release versions. Due to time and manpower constraints (we all work in our freetime on this project) we do not maintain release branches.
So, the master is always based on the latest release version + new features/bug fixes which have been merged since release, the latest commit level.

I understand. Well, thank you, above all, for the amazing product. I really like it and I really appreciate your work. In my opinion, JabRef is the only solution that I can use with my git-tracked documents.

Just out of curiosity: Why don't you use prebuilt jar version of the release?

Do you mean the jar-files in the releases section of the repository? Well, I can use them. I am used to building from source and tracking git repositories. Other than that, for JabRef especially, I would not mind the prebuilt binary, I suppose. I have a script that traverses my git repositories in a folder and checks for new upstream releases.

One question though. I am not knowledgeable about Java, and forgive me if the question is _very_ stupid. Will it matter if I use Oracle version or the OpenJDK version, on my machine, when it comes to using the prebuilt binaries?

[tobiasdiez]

Oracle vs OpenJDK does not really matters. We had some troubles with OpenJDK in the past, but they should be fixed if you use recent versions (of JabRef and of OpenJDK). So it comes down to your personal preference and what's easier to install and run on your particular system.

Since the original problem is fixed in master, I'll close this issue now.

[aytekinar]

Thank you, both of you, @Siedlerchr and @tobiasdiez for your prompt responses.

[koppor]

@aytekinar I think, you are a pro and know that JabRef depends on javafx. I think, the arch package is prepared for that. For the other distros, we have a howto here: http://help.jabref.org/en/Installation#installation-commands

Our main slogan for the master branch is:

The master branch is always release ready

No separate develop branch. "master" is the main integration branch and we always use that version in our daily scientific work.

We know about release early, release often, but we try to collect new features together.

For internal reference: The compile error got fixed at https://github.com/JabRef/jabref/pull/3623.

[aytekinar]

Thank you, @koppor, for clarifying the master branch issue. I will follow this branch and install whenever I feel like it :)

I think, you are a pro and know that JabRef depends on javafx.

Yes, I realized it a couple of versions ago, and I installed it:

 ~  pacman -Ss javafx
extra/java-openjfx 8.u172-1 [installed]
    Java OpenJFX 8 client application platform (open-source implementation of JavaFX)

I think, the arch package is prepared for that. For the other distros, ...

So, you say that I am safe with openjfx installation I have? Sorry for asking this again; but as I said, I am a noob when it comes to Java --- I have not programmed Java in my life, and I do not know what different implementations mean :)

[koppor]

@aytekinar I would say so. We had issues with old OpenJFX packages, but arch always ships the newest ones, so this is good to go!