Bug 989946 - (f-r_detects_java-issues_in_c_pkg) detects java-issues in c[++]-pkg
detects java-issues in c[++]-pkg
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: fedora-review (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Stanislav Ochotnicky
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-30 04:03 EDT by Björn "besser82" Esser
Modified: 2013-08-30 09:27 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-08-30 09:27:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
review-report && build.log of rhbz# 989752 (14.21 KB, application/x-bzip)
2013-07-30 04:03 EDT, Björn "besser82" Esser
no flags Details

  None (edit)
Description Björn "besser82" Esser 2013-07-30 04:03:13 EDT
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
Comment 1 Alec Leamas 2013-07-30 04:20:48 EDT
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
Comment 2 Stanislav Ochotnicky 2013-07-30 04:33:19 EDT
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.
Comment 3 Stanislav Ochotnicky 2013-07-30 04:51:38 EDT
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
Comment 4 Alec Leamas 2013-07-30 05:35:39 EDT
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?
Comment 5 Alec Leamas 2013-07-30 06:01:11 EDT
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 ;)
Comment 6 Alec Leamas 2013-08-15 07:17:35 EDT
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.
Comment 7 Stanislav Ochotnicky 2013-08-19 10:51:12 EDT
I have reconsidered and reworked triggers for running Java plugin. This is fixed in commit ebfc19e13 upstream and will be included in next release
Comment 8 Alec Leamas 2013-08-30 09:27:48 EDT
Closing bug with new 0.5.0 release. Thanks for reporting, feel free to reopen if problem persists.

Note You need to log in before you can comment on or make changes to this bug.