java-utils-2.eclass: Call eapply_user and drop java_prepare for EAPI 6

Although simply calling default sounds like a good idea, if an ebuild
needs to use multiple eclasses that call default then patching will
break as PATCHES will be applied more than once. eapply_user, on the
other hand, is idempotent. If an ebuild needs to apply PATCHES then it
should define src_prepare and call default explicitly. This will
probably be improved in EAPI 7.

java_prepare is being dropped because non-Java people find it
confusing and it isn't consistent. Other eclasses don't do this and we
don't apply the same rule to other phases either.

diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index 82dec00cf2f5113a7408a83d73551beac316ae49..ee4c31991407631be3f548926c8996e20d41942c 100644 (file)
--- a/eclass/java-utils-2.eclass
+++ b/eclass/java-utils-2.eclass
@@ -275,7 +275,7 @@ java-pkg_addres() {
 # be it a unit test or a regular java class.
 #
 # You can use this function by either:
-# - calling it yourself in java_prepare() and feeding java-pkg_rm_files with
+# - calling it yourself in src_prepare() and feeding java-pkg_rm_files with
 # the list of files you wish to remove.
 # - defining an array in the ebuild named JAVA_RM_FILES with the list of files
 # you wish to remove.
@@ -1867,7 +1867,14 @@ ejunit4() {
 # src_prepare Searches for bundled jars
 # Don't call directly, but via java-pkg-2_src_prepare!
 java-utils-2_src_prepare() {
-       java-pkg_func-exists java_prepare && java_prepare
+       case ${EAPI:-0} in
+               [0-5])
+                       java-pkg_func-exists java_prepare && java_prepare ;;
+               *)
+                       java-pkg_func-exists java_prepare &&
+                               eqawarn "java_prepare is no longer called, define src_prepare instead."
+                       eapply_user ;;
+       esac
 
        # Check for files in JAVA_RM_FILES array.
        if [[ ${JAVA_RM_FILES[@]} ]]; then