It would be nice to have a recent jabref in gentoo.
I guess it is not trivial.
James already had a short look at the old ebuild in https://bugs.gentoo.org/show_bug.cgi?id=579818
Currently jabref is built with gradle which we don't have in tree. How would we build jabref?
Nicolas, thank you for pointing out that we need gradle. Now I remember, that we had been at this point in spring this year already.
*** Bug 608742 has been marked as a duplicate of this bug. ***
Just for information: JabRef 2.10 was the last version built with gradle.
There is not much magic being done in the gradle build (see https://github.com/JabRef/jabref/blob/master/build.gradle):
- generating source using antlr
- generating source using xjc
- patching in VERSION and DEVELOPERS in the source files
- declaring dependencies
- making a fat jar and some magic so that it works with gradle
Other things not required for a binary:
- some Install4J thing - windows + mac only
In case someone has experience with other build tools (Maven?) it should not be that hard to write a pom.xml doing the build for JabRef.
FYI, here what debian did to package 3.8.2:
Debian's patch to build.gradle is available at https://anonscm.debian.org/git/pkg-java/jabref.git/tree/debian/patches/010_gradle_build.patch
The also had issues to get xjc running, thus they added the generated files: https://anonscm.debian.org/git/pkg-java/jabref.git/tree/debian/patches/030_xjc.patch
And the usual org.json replacement patch: https://anonscm.debian.org/git/pkg-java/jabref.git/tree/debian/patches/050_unirest_json.patch
Finally, due to non-available libraries, some functionality has been removed and a DB driver replaced: https://anonscm.debian.org/git/pkg-java/jabref.git/tree/debian/patches/001_koppor_debian.patch
All external libraries are listed at https://github.com/JabRef/jabref/blob/master/external-libraries.txt - required for the upcoming version 4.0 of JabRef relying on JavaFX being available.
Version 3.8.2 does not rely on JavaFX. Its external libraries are listed at https://github.com/JabRef/jabref/blob/v3.8.2/external-libraries.txt
Sure, the dependencies stated at build.gradle are the ones really used: https://github.com/JabRef/jabref/blob/v3.8.2/build.gradle#L70
(In reply to koppdev from comment #5)
> All external libraries are listed at
> https://github.com/JabRef/jabref/blob/master/external-libraries.txt -
> required for the upcoming version 4.0 of JabRef relying on JavaFX being
FYI, JavaFX is now in Gentoo tree but now called dev-java/openjfx
Should this ebuild be eliminated and jabref-bin left as the only jabref ebuild in the tree? Jabref 2.x is more than 5 years old and jabref 5.x is the latest stable.
I only have 2c worth adding here. I remember reading in the documentation that philosophically source builds are preferred over binary builds when possible.
That said, I am not an official gentoo developer. If one of the official maintainers are willing to mentor me through the process of becoming an official developer I will commit to helping upgrade jabref-bin to 5.0 and do my best to get jabref source build updated as well (as well as modernizing them to EAPI=7 or jabref to 6 at the preference of the sci team). My biggest issue here is that of the roughly 40 different languages I have programmed in non-trivially over my career, java is not one of them, so that will be a learning curve.
Also to note, I have been using Jabref on and off since 2008 or before (that is the oldest email I can find referring to jabref), and would really like to get some of these issues resolved.
Anyway, if any devs are willing to work with me to mentor, then I will look at my schedule and see how much time I can start breaking away for this.
@Java team, are you interesting in mentoring EBo?