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 - checkstyle - modernizer - junit 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 > available. 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?
*** Bug 765439 has been marked as a duplicate of this bug. ***
@Benda Xu, I never heard back from anyone. Sad that. Oh well.
(In reply to John (EBo) David from comment #11) > @Benda Xu, I never heard back from anyone. Sad that. Oh well. Don't give up, please. Any help in getting jabref bumped to an up-to-date version will be highly appreciated. Discussions are usually done mainly in #gentoo-java on libera.chat (see https://www.gentoo.org/get-involved/irc-channels/).
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f311853431ea7ce292d6fa9604f8eb99ff776951 commit f311853431ea7ce292d6fa9604f8eb99ff776951 Author: Jakov Smolić <jsmolic@gentoo.org> AuthorDate: 2022-05-29 07:18:25 +0000 Commit: Jakov Smolić <jsmolic@gentoo.org> CommitDate: 2022-05-29 07:18:25 +0000 app-text/jabref: treeclean Closes: https://bugs.gentoo.org/792606 Closes: https://bugs.gentoo.org/600698 Signed-off-by: Jakov Smolić <jsmolic@gentoo.org> app-text/jabref/Manifest | 1 - .../files/jabref-2.10-javax.swing-java-9+.patch | 313 ------------------ .../files/jabref-2.10-skip-failing-tests.patch | 349 --------------------- .../files/jabref-2.10-test-jvm-props-args.patch | 49 --- app-text/jabref/files/jabref-2.10-test-prefs.xml | 19 -- app-text/jabref/jabref-2.10-r7.ebuild | 132 -------- app-text/jabref/metadata.xml | 19 -- profiles/package.mask | 6 - 8 files changed, 888 deletions(-)
