Created attachment 780398 [details] review-report && build.log of rhbz# 989752 Description of problem: f-r detect java-related issues on a package with nothing java-related in src. Version-Release number of selected component (if applicable): 0.4.1-2.fc19 How reproducible: 100% Steps to Reproduce: 1. invoke `fedora-review -m fedora-rawhide-x86_64 -b 989752` 2. wait for run to finish 3. look inside review.txt Actual results: - Javadocs are placed in %{_javadocdir}/%{name} (no -%{version} symlink) Note: No javadoc subpackage present See: https://fedoraproject.org/wiki/Packaging:Java#Javadoc_installation - Fully versioned dependency in subpackages, if present. Note: Missing: Requires: %{name} = %{version}-%{release} in SDL2-devel, SDL2-static See: http://fedoraproject.org/wiki/Packaging/Guidelines#RequiringBasePackage ---> false-positive (possible bug), are present in arched-form and should be this way - Packages have proper BuildRequires/Requires on jpackage-utils See: https://fedoraproject.org/wiki/Packaging:Java - Javadoc documentation files are generated and included in -javadoc subpackage Note: No javadoc subpackage present See: https://fedoraproject.org/wiki/Packaging:Java#Javadoc_installatio Expected results: Since there is nothing about Java in src, it shouldn't report issues about Additional info: Affects rhbz# 989752
Besides that this issue needs to be investigated, it seems a bit awkward to block the review on this. IMHO, if you are positive that the java-related messages are bogus you should just not paste them into the bug. After all, you are the reviewer. f-r is just a tool with limitations
f-r runs java tests because "android-project" tarball subdirectory contains java files. In this instance f-r was incorrect, but I'd rather have it run unneeded tests that are easily block-removed than not to run tests that should have been run. We could make it look in binary RPM instead of tarball for hints wrt what type of package it is, but I'd rather stay with current approach.
I am more inclined to change this issue around a bit perhaps. Let's make it more visible why certain class of tests is running. Each group would have a list of reasons why its tests are running. Example output (just a quick proposal) Java: pom.xml[1, sources], *.java[25, sources], *.jar [1, rpm] python: *.py[10, sources, rpm] Or something similar. I'd like it to be short of course
If the spec removed the android-project subdir in %prep (it probably should) f-r would still run java tests since we check self.check.sources. Using self.buildsrc would rectify this. Still, I'm a bit puzzled about classifying something with a .java sourcefile as a java package?! Nothing but a java package would contain a .pom file, agreed. But shouldn't the .java file test be for what's shipped in the rpms? In other words. what kind of java package contains a java file, no .pom file and generates neither .jar nor .java files?
We dont' check the generated rpms for .class, .war or .ear files. This should really be fixed. My gut feeling is that we should only run java tests based on what's in the rpms, with the exception of .pom files in the sources. Perhaps we could also issue a warning if we find .java files in the sources but don't deem the package as a java one. Which brings up the idea to somehow force running tests in a particular plugin, basically disabling the automatic 'is_applicable()' function. We could certainly add more info the the template, but then we will have to find a way to force reviewers not to include it in the bug ;)
With current devel, it's possible to manually disable the java plugin. This should handle the most obvious issues here. Although I still think tests basically should be based on what's in the rpms it's just not that important anymore.
I have reconsidered and reworked triggers for running Java plugin. This is fixed in commit ebfc19e13 upstream and will be included in next release
Closing bug with new 0.5.0 release. Thanks for reporting, feel free to reopen if problem persists.