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.
This commit is contained in:
James Le Cuirot
2016-10-17 16:03:49 +01:00
parent 74fd2b94e7
commit 4f7bb1bd2e

View File

@@ -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