Package Details: eclipse-java 2:4.21-1

Git Clone URL: (read-only, click to copy)
Package Base: eclipse-java
Description: Highly extensible IDE (Java version)
Upstream URL:
Keywords: ide
Licenses: EPL
Conflicts: eclipse
Provides: eclipse=4.21-1
Submitter: altermetax
Maintainer: altermetax (morgenstern)
Last Packager: altermetax
Votes: 23
Popularity: 3.34
First Submitted: 2021-08-21 23:38
Last Updated: 2021-09-15 14:42

Dependencies (3)

Required by (58)

Sources (2)

Latest Comments

1 2 3 Next › Last »

altermetax commented on 2021-09-16 16:50

Alright, thank you for dealing with the merge request :)

morgenstern commented on 2021-09-16 04:58

The TUs evidently are not keen on dropping the "-bin" prefix. I will make an appeal on historical grounds, but if no dice then we should look to merge this package into eclipse-java-bin and I will add you as a co-maintainer there.

EDIT - on reconsideration, the TUs are happy to merge. New request submitted.

morgenstern commented on 2021-09-15 01:55

Thanks, just did a clean chroot build of eclipse-java - there were a few dependencies flagged as unneeded:

eclipse-java W: Dependency included and not needed ('webkit2gtk')
eclipse-java W: Dependency included and not needed ('unzip')

Digging into it, webkit2gtk is used by org.eclipse.swt, so that should probably stay. As for unzip, I presume that is needed by Eclipse to support importing archives in ZIP format, so that should also remain.

As for the dependencies listed in eclipse-java-bin, it looks like python is implicitly installed according to the eclipse-java build log, so that can be dropped, and libsecret is a dependency of webkit2gtk, so that can be dropped as well.

Merge request coming shortly - cheers.

altermetax commented on 2021-09-15 01:07

Added you as a co-maintainer :)

At this point the same should be done with eclipse-jee-bin and eclipse-cpp-bin though, I'll contact the maintainers.

morgenstern commented on 2021-09-15 00:42

No worries - I've had a read of your PKGBUILD as well and I agree with your recommendations around the icons and ensuring eclipse.ini is included the backup array.

As for shifting the binaries out of /opt, even if historically Eclipse was installed to /usr/lib the standard practice is to place pre-built binaries in /opt. That being said, it sounds like this makes it harder to add plugins and addons to Eclipse via pacman/AUR helper. The following bug report discusses the pros and cons of following this approach. Based on this commit, it looks like the old official [community] PKGBUILD installed the binaries directly into /usr/lib too, so I grudgingly agree that the installation path can change. :)

It also looks like the -bin prefix is pretty much dispensed with when it comes to packaging Eclipse binaries, so perhaps I should be the one merging into your package. If you would accept a merge and be happy to add me as a co-maintainer, I will go ahead and file the requests.

altermetax commented on 2021-09-14 23:49

Oh, I had no idea of the existence of that package.

I originally took over the eclipse split package (which has existed for a long time) and realized its PKGBUILD was not suitable at all for the AUR, so I requested splitting it into multiple packages, writing their PKGBUILDs from scratch (-java, -jee, -cpp, -php), and that is its current state.

I agree with merging, however I've read your PKGBUILD and there's a few things which might need addressing:

  • Eclipse gets installed in /opt/eclipse while most AUR packages that depend on eclipse expect it in /usr/lib/eclipse (which was its location back when eclipse was in the official repositories)

  • The icons get installed in /usr/share/pixmaps while the usual location for icons is /usr/share/icons/hicolor (this is not a requirement but most graphical programs on Arch put icons there). Also, the eclipse icons are provided in the tarball, there's no need to have them in the AUR files. It would also probably be good to install all the sizes instead of just one.

  • Another tiny thing: eclipse.ini is not in backup (read the comments at

morgenstern commented on 2021-09-14 22:35

This package appears to be a near-duplicate of eclipse-java-bin, which I maintain. As the package I maintain has the correct naming schema (-bin prefix) and already exists, I would recommend either deleting this package or merging it into mine. I am happy to add you as a co-maintainer if you're interested.

LaughingMan commented on 2021-09-05 00:13

Sure, that's what .pacnew files are for after all. I mainly wanted to provide a fix to anyone who's encountering the same problem. Making you aware was secondary at best, since it's unclear to me what you could reasonably do about it. Maybe some sed magic in an install script, but that might be a bit fragile, too...

altermetax commented on 2021-09-04 20:33

That behavior is because eclipse.ini can be a configuration file and it can be modified by users, so it doesn't get updated if it was modified. See the comments here:

LaughingMan commented on 2021-09-04 07:15

For anyone else who got an error message saying "The Eclipse executable launcher was unable to locate its companion shared library" after updating to version 4.20: When running the eclipse command from the terminal it showed

plugins/org.eclipse.equinox.launcher.gtk.linux.x86_64_1.2.0.v20200915-1442: cannot open shared object file: No such file or directory

That file was still referenced in /usr/lib/eclipse/eclipse.ini. This package currently doesn't update or overwrite that file, but it does put a eclipse.ini.pacnew containing the updated version right next to it. Since I didn't modify the original eclipse.ini, simply replacing it with the provided eclipse.ini.pacnew fixed the issue for me.