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.

1 files changed, 9 insertions, 2 deletions

diff --git a/eclass/java-utils-2.eclass b/eclass/java-utils-2.eclass
index 82dec00cf2f5..ee4c31991407 100644
--- 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