The java-ant_remove-taskdefs() function has a bunch of Python code that implies direct dependency on Python. That's a bad idea and -- unless I'm missing something -- it requires Python with USE=xml. Therefore, the snippet can pretty easily fail with what your dependency can't enforce. Could you please move it to javatoolkit as a separate tool? This way, javatoolkit would enforce proper Python deps, the wrapper would choose a proper implementation and everything would unconditionally work fine. The eclass adds dependency on javatoolkit anyway, so that wouldn't be a problem.
Ping. Any chance to fix this?
Ah, another weekly reminder. Looked into the consumers this time, there are only two; do we even want to retain this functionality at all if nobody ever uses it? It seems that these could just be replaced by build.xml patches for now. Then if we want to do proper build.xml tool based patching later we can implement that in a later generation of the eclass and/or the Java tools. Java team, ping, any other thoughts? Agree? Disagree? TYIA For reference: $ grep -r java-ant_remove-taskdefs /usr/portage/ /usr/portage/dev-java/jspeex/jspeex-0.9.7.ebuild: java-ant_remove-taskdefs --name proguard /usr/portage/app-misc/freemind/freemind-0.9.0-r1.ebuild: java-ant_remove-taskdefs --name jarbundler # macOS only /usr/portage/eclass/java-ant-2.eclass: # java-ant_remove-taskdefs /usr/portage/eclass/java-ant-2.eclass: # @FUNCTION: java-ant_remove-taskdefs /usr/portage/eclass/java-ant-2.eclass: java-ant_remove-taskdefs() { $
Ping. Could we move on, please?
+ 18 Feb 2014; Tom Wijsman <TomWij@gentoo.org> + +files/jspeex-0.9.7-remove-proguard-taskdef.patch, +jspeex-0.9.7-r1.ebuild, + -jspeex-0.9.7.ebuild, files/jspeex-0.9.7-remove-junit-report.patch: + Replace java-ant_remove-taskdefs by a patch, see bug #479838. + 18 Feb 2014; Tom Wijsman <TomWij@gentoo.org> +freemind-1.0.0-r1.ebuild, + -freemind-1.0.0.ebuild: + Remove java-ant_remove-taskdefs as the taskdef is no longer present, see bug + #479838. This last one needs stabilization in order to proceed, will block this bug.
*** Bug 475346 has been marked as a duplicate of this bug. ***
Please move. On a ~arch system using default PYTHON_TARGETS python:3.4 gets pulled in. (I know, that's not dramatic, but inconvenient)
(In reply to Tom Wijsman (TomWij) from comment #4) > + 18 Feb 2014; Tom Wijsman <TomWij@gentoo.org> +freemind-1.0.0-r1.ebuild, > + -freemind-1.0.0.ebuild: > + Remove java-ant_remove-taskdefs as the taskdef is no longer present, see > bug > + #479838. > > This last one needs stabilization in order to proceed, will block this bug. app-misc/freemind/freemind-0.9.0-r1 seems to be the only remaining consumer of the function. Once 1.0.0-r1 is stable on ppc and x86 (see blocking bug) we can drop it.
+ 31 Mar 2014; Michał Górny <mgorny@gentoo.org> freemind-0.9.0-r1.ebuild: + Move the java-ant_remove-taskdefs function from the ebuild since this ebuild + is the last consumer of it. This is least-change way of fixing the eclass. + 31 Mar 2014; Michał Górny <mgorny@gentoo.org> java-ant-2.eclass: + Ban the java-ant_remove-taskdefs() function and remove Python dependency, bug + #479838. Hope you don't mind, this should make us much happier now.
