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

Problem when building from source for v4.1 #3657

Closed
1 task
aytekinar opened this issue Jan 22, 2018 · 9 comments
Closed
1 task

Problem when building from source for v4.1 #3657

aytekinar opened this issue Jan 22, 2018 · 9 comments

Comments

@aytekinar
Copy link

aytekinar commented Jan 22, 2018

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<Path> 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<Path> 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
Copy link
Member

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

@aytekinar
Copy link
Author

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
Copy link
Member

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
Copy link
Author

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
Copy link
Member

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
Copy link
Author

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

@koppor
Copy link
Member

koppor commented Jan 24, 2018

@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 #3623.

@aytekinar
Copy link
Author

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
Copy link
Member

koppor commented Jan 24, 2018

@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!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants