Arch Linux

This is intentional and correct. Look at the packages, they include conflicting files.

The should be able to be installed together - and they were until the update. It is a very, very common usage to need both installed at once. This packaging needs fixed.

One of the purpose of packaging is to keep required patches together with stuff obtained from upstream.

I can see the source of the confusion.

The packages eclipse-java, eclipse-cpp, eclipse-php each now stand for a self-contained Eclipse *product*, not just one or more Eclipse *features* to be added to an existing product (like the old eclipse-cdt package). This is why all of these packages provide and conflict with the eclipse (virtual) package.

The eclipse-common package merely contains files common to all of these product packages, to save disk space on the mirrors. It is _not_ a skeleton Eclipse product meant for adding features onto.

Products and features: http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fproduct_configproduct.htm&cp=2_0_21_0_1

A brief read of Eclipse documentation referenced on creating products suggests it is aimed at people supplying a specialised, possibly proprietary, tool not a general purpose development environment. When such a tool was distributed and installed it would be self-contained and thus even if it contained files that were actually common to some other Eclipse-based products the product being installed would have its own copies.

If one wanted to apply that philosophy to Java and C++ developments, i.e. define each as a product then the common package approach and conflicts is not consistent with that philosophy. What would need to happen instead is that each product package would need to be self-contained and not use any filesystem paths included in the other package even if that meant duplicating 99% of the files. Despite not being very efficient on storage most people installing would probably prefer that approach to a complete inability to install both at once.

A better approach, in my view, would be retain the "core" or "common" package and go back to having packages for the relevant plugins for various languages and development tasks. The core package could contain some scripting such that as the optional packages are installed/uninstalled files that enumerate what is installed, and would therefore conflict if simply included in the option packages, would be generated automatically from what is actually installed.

What actually happened - Eclipse developers made life of downstream packages maintainers extremely uncomfortable. I see no simple solution.

@xoid Seconded.
Eclipse is not a simple application but an entire ecosystem, with its own package manager, plugin system and dependency hell sploshed into a fishbowl. We may be thankful that the Eclipse developers made it (somewhat)[1] possible at all to install an Eclipse product package in a system area (where normal users don't have write access).

@Amphitryon Modular Eclipse packaging by distributions is _by no means_ a simple task, it involves much more than simply splitting the whole thing up in a set of plugins. There is dependency hell, not all combinations of features work (well) with the same versions of plugins, not all plugins can coexist within the installation, etc., etc.
To get an inkling of the sheer complexity involved in modular Eclipse packaging, have a look at [2].
I can entirely understand that Arch Linux, striving for mostly vanilla, unpatched packages, doesn't want to go that way.

My personal tip: if you want to use Eclipse with more than a few extra features besides those of one of the main development products, by all means download, unzip and run one of the prebuilt product packages somewhere in your home directory, then add features using the "Install new software" menu choice. Don't try and pimp a "shared" installation with lots of extra plugins and features, things will break, often in very frustrating ways.

[1]: https://bugs.eclipse.org/bugs/show_bug.cgi?id=281510
[2]: https://github.com/eclipse/linuxtools.eclipse-build

I've added a feature request for this but maybe my proposal should be here aa a possible fix for the reported bug. Please see: https://bugs.archlinux.org/task/48562

When upgrading eclipse I get the following error because I use java and cpp.

# pacman -Su
:: Starting full system upgrade...
:: Replace eclipse with extra/eclipse-java? [Y/n]
:: Replace eclipse-cdt with extra/eclipse-cpp? [Y/n]
resolving dependencies...
looking for conflicting packages...
error: unresolvable package conflicts detected
error: failed to prepare transaction (conflicting dependencies)
:: eclipse-java and eclipse-cpp are in conflict

This is because the packages eclipse "product" packages have overlapping files.

One suggested resolution is to only install one of the products, i.e. java or cpp and then add support for the other product via the eclipse installation mechanisms.

The way that I think it could be resolved is to have the 3 current product packages installed in their own directory and linked with standard eclipse mechanism for product extensions.

This mechanism is described here: http://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Fguide%2Fproduct_extension.htm

I think they should be installed as follows:

-------------

eclipse-common remains unchanged but for the addition of the "links" directory
add directory: /usr/lib/eclipse/links

-------------

eclipse-java is installed in to /usr/lib/eclipse-java/eclipse
add empty file: /usr/lib/eclipse-java/eclipse/.eclipseextension
add link file: /usr/lib/eclipse/links/eclipse-java.link whose contents would then be:

path=/usr/lib/eclipse-java/eclipse
name=Eclipse Java Developer Toolkit
id=org.eclipse.jdt
version=4.5.2

-------------

eclipse-cpp is installed in to /usr/lib/eclipse-cpp/eclipse
add empty file: /usr/lib/eclipse-cpp/eclipse/.eclipseextension
add link file: /usr/lib/eclipse/links/eclipse-cpp.link whose contents would then be:

path=/usr/lib/eclipse-cpp/eclipse
name=Eclipse C Developers Toolkit
id=org.eclipse.cdt
version=4.5.2

-------------

eclipse-php is installed in to /usr/lib/eclipse-php/eclipse
add empty file: /usr/lib/eclipse-php/eclipse/.eclipseextension
add link file: /usr/lib/eclipse/links/eclipse-php.link whose contents would then be:

path=/usr/lib/eclipse-php/eclipse
name=Eclipse PHP Developers Toolkit
id=org.eclipse.php
version=4.5.2

-------------

Wouldn't it be possible to provide a single package, which just installs the Eclipse Platform Runtime Binary.
This would be a bare minimum Eclipse installation.
Users could then install plugins they want within Eclipse itself.

Edit: Sry, I missed that there is already an eclipse-platform package in the aur, which could be used just for this purpose.

Someone is working on this, reopening so they can post patches here

This patchfile should do the necessary changes to get multiple versions of Eclipse working side-by-side.

Thanks for the patch. Unfortunately it doesn't work here:

!SESSION 2020-04-08 10:51:39.270 -----------------------------------------------
eclipse.buildId=unknown
java.version=1.8.0_242
java.vendor=Oracle Corporation
BootLoader constants: OS=linux, ARCH=x86_64, WS=gtk, NL=es_ES
Command-line arguments: -os linux -ws gtk -arch x86_64

!ENTRY org.eclipse.osgi 4 0 2020-04-08 10:51:39.617
!MESSAGE Application error
!STACK 1
java.lang.IllegalStateException: Unable to acquire application service. Ensure that the org.eclipse.core.runtime bundle is resolved and started (see config.ini).
at org.eclipse.core.runtime.internal.adaptor.EclipseAppLauncher.start(EclipseAppLauncher.java:81)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:401)
at org.eclipse.core.runtime.adaptor.EclipseStarter.run(EclipseStarter.java:255)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:657)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:594)
at org.eclipse.equinox.launcher.Main.run(Main.java:1447)
at org.eclipse.equinox.launcher.Main.main(Main.java:1420)

Whoops, invoked the correct binary in the wrong location.

The attached patch should work as expected.

The patch will require manual intervention when updating from users, as Eclipse will read from a variant-specific directory for config and data instead of from the generic directories it would have been reading beforehand, btw.