Fix remaining packages that cannot be built from source

[Leo3418]

GSoC Idea

Resolving this issue is a good objective for a Gentoo GSoC project. Interested in participating in GSoC? You are invited to apply as a GSoC contributor! Please find more information on Gentoo Wiki as well as Google's program homepage.

You are still welcome to resolve this issue without participating in GSoC - just submit a pull request containing the fix!

Issue Description

Every Gentoo package should be built from source, unless the package is designated to be a binary one. Generally, such a binary package is created due to one of the following reasons:

1. There is another ebuild for the same package that builds from source, but the package takes a very long time to build on mainstream computers. In this case, the package's name will usually have the -bin suffix. Example: app-office/libreoffice-bin, which is the pre-built counterpart of app-office/libreoffice
2. The package that is hard to be built from source within Portage, possibly because its build system has not been integrated with Portage yet, and there is not a good way to build the package while circumventing the build system. In this case, the package's name will often bear the -bin suffix too, and the counterpart without the suffix does not exist. Example: dev-java/maven-bin, which does not have a dev-java/maven counterpart
3. The package's source files are not available at all. Example: net-im/zoom

Virtually all Java packages in the Spark overlay are intended to support building from source, but there are still a few packages that do not support it and thus directly install a pre-built binary JAR instead, which should be fixed.

There are three types of packages that install a pre-built binary JAR in the Spark overlay:

1. Packages that download a sources JAR from Maven Central (i.e. a JAR containing *.java source files), but the source files in the JAR cannot be compiled due to missing dependencies, missing files, incompatibility with latest JDK versions, etc., so the binary USE flag is enabled for the packages by default via IUSE="+binary".
2. Packages that do not download a sources JAR but are known to have available source code, hence their package names end with -bin. Most packages of this type are hard to build within Portage without using Maven or Gradle, but it might be still possible to do so.
3. Packages that do not download a sources JAR, and whether or not their source code is available is unknown.

To find each type of packages, the following commands may be used:

1. git grep -l 'IUSE=".*+binary.*"'
2. find * -type d -name '*-bin'
3. git grep -l 'inherit .*java-pkg-binjar'

For each type of packages, the following fixes should be attempted:

1. If possible, resolve the issues noted in the comment above the IUSE="+binary" line in the ebuild, so the package can be built from source without errors. Afterwards, remove IUSE="+binary" from the ebuild.
   If it is too hard or not even possible to fix the issues at all, then as a last resort, create a new ebuild, which has the -bin suffix in its PN, does not provide the binary USE flag anymore, and installs the pre-built JAR directly. One existing example is dev-java/lombok and dev-java/lombok-bin.
2. Try to create an ebuild that builds the package from source. If successful, create a new ebuild that does not have the -bin suffix in its PN. This is likely to be extremely hard because it would usually mean that creation of a non--bin package had already been attempted but to no avail, so the -bin package was created as a last resort.
   If it is not successful, just leave the -bin package as-is, but it might be helpful to add a comment to the ebuild explaining what has been tried in the attempt and what issues prevented it from succeeding.
3. Try to find the package's source files online. For Java packages whose sources JAR is not available on Maven Central, chances are there is still a copy of the source files in a VCS repository or on an obscure website.
   If the source files can be found, try to create an ebuild that builds the package from them. If the ebuild works, congratulations! Otherwise, create a -bin package for it, and consider to leave a comment that explains where the source files were found and why they could not be compiled.
   If the source files cannot be found, then just leave the package as-is.